How to add AI memory to your WhatsApp chatbot
Learn how to add AI memory to your WhatsApp chatbot using Redis — how it works, why it matters, and how CodeWords handles it automatically for you.
Rebecca Pearson5 min read
When someone messages your WhatsApp bot for the second time, does it remember them? In most basic setups, the answer is no — and that creates a deeply frustrating experience. The customer has to re-explain who they are, what they ordered, what they asked before. They feel like a stranger every time they get in touch.
AI memory is what changes that. This guide explains how memory works in WhatsApp bots, how Redis makes it reliable, and how CodeWords includes this automatically so you don't have to build it yourself.
TL;DR
- WhatsApp messages arrive independently — each one is a separate HTTP request with no built-in link to previous messages.
- Redis solves this by storing conversation history keyed to each user's phone number, so the AI always has context.
- CodeWords includes Redis memory by default — per-user isolation, configurable window, and automatic TTL management.
Why adding AI memory to your WhatsApp chatbot is harder than you'd expect
If you've built a web chatbot, you might assume WhatsApp works the same way — a session stays open while the user is active and closes when they leave. That's not how WhatsApp works.
Every WhatsApp message arrives at your server as a separate, independent webhook event. There's no session. There's no thread ID that persists across messages. From the perspective of your bot's code, each message from the same customer looks like a brand new request.
This means that without an explicit memory layer, your bot will respond to "what about the second option you mentioned?" with absolutely no idea what the customer is referring to. It doesn't know it said anything. It doesn't know this is the same person who messaged five minutes ago.
For a simple FAQ bot that just answers questions without needing context, this might be fine. For any bot that guides a customer through a multi-step flow, qualifies a lead, or handles a booking — memory is essential.
How Redis solves it
Redis is an in-memory key-value store. It's extremely fast — reads and writes happen in microseconds — and it's well-suited to storing temporary conversation state.
Here's how it works in a WhatsApp context:
Storing messages: every time a customer sends a message and the bot replies, both the user's message and the bot's response are appended to a list in Redis. The key for that list is the customer's WhatsApp phone number.
Retrieving history: when the next message arrives, the bot looks up the phone number in Redis and retrieves the conversation history. That history gets included in the prompt sent to the AI model — so the model knows exactly what was said before.
The memory loop: retrieve → pass to AI → generate reply → save new exchange → send reply. This runs on every message and keeps the conversation coherent.
Configuring the memory window
You don't want to pass the entire conversation history to the AI on every message. Token limits are finite, long histories can confuse the model, and storing unlimited history indefinitely has cost and storage implications.
The two key parameters to configure are:
Message window (N): how many previous exchanges to include. Typically the last 10–20 messages is enough to maintain context without bloating the prompt. You can adjust this based on how long your typical conversations run.
Time-to-live (TTL): how long Redis keeps the conversation history. A 24-hour TTL means the bot remembers everything within a single conversation but starts fresh the next day. A seven-day TTL is better for ongoing customer relationships. You might set a 30-day TTL for a booking assistant where context about previous appointments matters.
The right settings depend on your use case. A lead qualification bot might only need a four-hour TTL. A customer service bot for an existing customer base might want 30 days.
Per-user isolation
One of the most important properties of a well-built memory system is that each user's context is completely isolated from every other user's context.
This might sound obvious, but it's possible to build this wrong. If your memory implementation uses a shared buffer rather than per-user keys, a message from one customer could contaminate the context for another. That means a customer could see references to someone else's order, name, or conversation. That's both confusing and a potential data privacy problem.
Redis's key-value model makes per-user isolation natural. Each phone number gets its own key, and there's no way for one user's data to appear in another user's context unless you explicitly put it there.
The "reset" command
Sometimes customers — or your team during testing — need to clear the conversation history and start fresh. A common pattern is to listen for a specific message like "reset" or "start over" and delete the Redis key for that phone number when you receive it.
After the reset, the bot treats the next message as the start of a completely new conversation. This is useful for:
- Testing bot flows repeatedly without stale history interfering
- Letting customers restart a booking or qualification flow they abandoned
- Clearing out old context before a new use case (for example, a customer who used the bot for orders six months ago and now has a support question)
How CodeWords handles all of this
If you're building with CodeWords, you don't configure any of this manually. Memory is built into the platform.
When you describe your agent to Cody (the AI automation assistant), it automatically sets up Redis-backed conversation memory with per-user isolation. The memory window is configured sensibly by default, and you can ask Cody to adjust the TTL or window size as part of your agent description.
You don't write any Redis connection code. You don't manage TTLs. You don't implement the memory loop. Cody handles all of it, and your agent maintains coherent multi-turn conversations from the moment it goes live.
This is one of the less visible but more important differences between CodeWords and simpler automation tools like Zapier. Zapier processes each message in isolation — there's no memory layer, which means it can't hold a real conversation. CodeWords was built for exactly this kind of stateful, multi-turn interaction.
For more on how multi-turn conversations are structured, read our guide on how to build multi-stage WhatsApp conversation flows. And if you're new to building WhatsApp agents, how to build a WhatsApp AI agent in 2026 walks through the full setup.
Get started with CodeWords — your agent's memory layer is included from day one.