What a chatbot should remember, and what it should deliberately forget

A WhatsApp chatbot should remember the current conversation briefly and read customer facts from your records at the moment it needs them. It should deliberately forget sensitive incidental details, one-off instructions and anything the customer asked it to drop. More memory does not make a bot better, and what you keep matters more than how much.

Two different things get called memory. Conversation memory is the thread happening now. The customer record is what you know about the customer as a matter of record. They have different lifespans, different accuracy requirements and different consequences when they go wrong.

What we'll cover

• Two things called memory
• The conversation, and how much of it to carry
• The record, and what belongs in it
• Staleness is the main failure
• Building it with CodeWords
• Keeping people apart
• When remembering is the wrong thing to do
• Summaries, and what they quietly lose
• Starting again
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Key takeaways

• The conversation resolves references such as "yes" or "the second one", and the customer record supplies facts.
• Most memory failures are stale facts stated with confidence, so read facts at the moment of use.
• Phone numbers identify accounts, not people, so confirm identity before volunteering stored details.
• Approvals, prices, dates and instructions belong in structured fields, not in prose summaries.
• Testing the second conversation finds the problems that a fresh thread hides.

Two things called memory

Conversation memory is the last stretch of the current exchange, and the customer record is what your business knows about the customer. The design rule is simple: the conversation resolves references, and the record supplies facts.

• Conversation memory lets the bot resolve "yes", "the second one" and "no, the other date" without asking again. It is short-lived by design, it need not be accurate about the world, and losing it costs nothing beyond the current conversation.
• The customer record holds who the customer is, what you did for them, what they own and what they agreed. It is long-lived, it must be accurate, and it belongs in your systems, not in a chat history.

Mixing the two causes both failures. A bot that relies on chat history for facts about the customer will be confidently wrong about anything that changed. A bot with no conversation memory will ask someone's name three times in four minutes.

The conversation, and how much of it to carry

Carry only as much conversation as the bot needs to understand the latest message. Longer history is not better, for three reasons:

• Cost and latency. More history means more work on every message, and a bot that takes eight seconds to answer feels broken.
• Confusion. A long history contains contradictions, abandoned branches and corrections, and a model reading all of it can surface the wrong version.
• Irrelevance. A message from three weeks ago in the same thread is usually about something else.

Two limits work better than a fixed message count. Bound the history by time as well as length, so a conversation resumed after a fortnight does not drag the old one in. And bound it by topic, treating a clearly new request as a fresh start even in the same thread.

The test is whether a customer can say "actually, make it Thursday" and be understood. If that works, the window is long enough.

The record, and what belongs in it

The customer record should hold what the bot must be correct about, written deliberately and never inferred:

• Identity, as far as you have verified it.
• What you have done for the customer, and when.
• What they own or use, which for most trades is what makes the conversation useful.
• What they agreed, including anything they declined or asked you not to do.
• Their stated preferences: channel, times and how they want to be addressed.
• Their consent position, and what it covers.

Write each item at a moment you can point to, through a process you can describe. A record assembled by a model reading old conversations is a record you cannot defend, and when it is wrong about something consequential you will not know why.

Staleness is the main failure

Staleness is the main failure because most embarrassing memory errors are stale facts stated with confidence. An appointment moved, the customer sold the car, the address is old, or the customer asked you to stop contacting them and the system still holds an earlier preference. The bot is not inventing anything. It remembers accurately from a snapshot that has expired.

Three defences work:

1. Read facts at the moment you need them, not at the start of the conversation, since details may change between the first and fifth message.
2. Give facts an age, and treat older ones with more caution.
3. Confirm anything consequential instead of asserting it. "I have you down for the 14th at ten, is that still right?" costs one line and prevents the whole class of error.

Building it with CodeWords

To build memory in CodeWords, describe to Cody, the automation builder, what the bot recalls within a conversation, which facts it looks up and what it writes back. CodeWords offers 3,000+ integrations (CodeWords integrations page, 2026), and you connect each once and reuse it.

1. Open CodeWords and start a new automation.
2. Describe in plain language what the bot should recall within a conversation, what facts it should look up, and what it should write back.
3. Authorize the connections to whatever holds your customer records and to your WhatsApp Business Platform account, so facts come from the record and not from the thread.
4. Describe the exceptions: a returning customer after a long gap, a customer whose details changed, a shared number, and anyone who asked you to forget something.
5. Test the second conversation, not the first. Everything works on a fresh thread, and the problems appear on the return visit.

You describe the outcome, and Cody builds it, connects it and deploys it. The Free plan covers light use. Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Keeping people apart

Scope memory to a person, because a phone number identifies an account and is a weaker identifier than it looks. Numbers get recycled, couples share a handset, several staff may use one business number, and a parent may message about a child's appointment. In each case the history attached to the number belongs to more than one person. A bot that greets whoever messages with the last person's details has leaked information.

• Keep memory per conversation thread where you cannot tell people apart.
• Do not volunteer stored details unprompted.
• Confirm identity where it matters. Asking costs a line of text, while assuming can tell someone else's partner about an appointment.

When remembering is the wrong thing to do

Remembering is the wrong thing to do for four kinds of information, and building the reflex to discard is as important as building storage:

• Sensitive details volunteered incidentally. A customer who says they cannot attend because of a hospital appointment told you something you did not ask for and should not keep.
• Anything the customer asked you to forget. Acting on that promptly and completely is both a legal matter and a matter of trust.
• Anything stated as temporary. "Use my mum's address this once" is not a change of address, and systems that update the record anyway cause real problems.
• Inferences you would not say to the customer's face. If it would be uncomfortable to read aloud, do not store it as a fact about a person.

A record you would be embarrassed to show the customer is a record you should not keep.

Summaries, and what they quietly lose

Summaries compress a long conversation, and they lose conditions and qualifications first. A summary is a lossy, confident reconstruction, and the loss is invisible afterwards. "Customer approved the work" is a fine summary of an exchange where the customer approved the work subject to a price cap, yet the cap was the part that mattered.

Two rules apply:

1. Never summarise a commitment. Store approvals, prices, agreed dates and instructions as structured fields, verbatim, not as prose.
2. Keep the original beside the summary. The day the summary is wrong is the day someone needs the original.

Starting again

Give customers a discoverable way to clear the conversation and start fresh. It helps in three situations: a conversation that has gone wrong and is compounding, a customer switching to a different topic, and a customer who wants the bot to stop referring to earlier messages.

State plainly what clearing does. Clearing a conversation is not deleting the customer's data, and a customer who believes otherwise will be surprised later. A request to delete data is a different request, and it goes to a person.

Making it survive

The memory design survives growth when five habits hold:

• Read facts at the point of use, not at the start of the conversation.
• Write records deliberately, never by inference from chat history.
• Confirm anything consequential instead of asserting it.
• Apply retention to conversation history as well as to records.
• Test returning customers regularly, since staleness shows there.

Limits worth knowing about

The main limits are the weakness of long context, the weakness of phone numbers as identity, and the privacy cost of retention.

• Longer context is not better memory. Past a point it makes answers worse.
• Phone numbers identify accounts, not people.
• Summaries lose conditions, which are usually the important part.
• A model can be confidently wrong about its own history, so check anything it says about what was agreed against the record.
• More memory raises the privacy stakes, since everything remembered is something you hold and must account for.

What to build first

Build the separation first. Decide which facts come from the record and which references come from the conversation, and make the bot look facts up instead of recalling them. Nearly every memory failure worth worrying about comes from a fact remembered instead of read.

Two habits make the difference. Confirm consequential details out loud, because one line of text prevents the whole category of stale-fact errors. And test the second conversation, since a fresh thread always works and the return visit is where problems appear.

Frequently asked questions

What is the difference between conversation memory and a customer record?

Conversation memory is the recent thread, used to resolve references like "yes" or "the second one", and it is short-lived. The customer record is what your business knows, and it must be accurate. The conversation resolves references, and the record supplies facts.

How much conversation history should be carried?

Carry enough that a customer can say "actually, make it Thursday" and be understood. Bound the history by time and topic as well as length, since more history adds latency and introduces contradictions.

What should go in the customer record?

Include verified identity, what you have done, what the customer owns, what they agreed or declined, stated preferences and their consent position. Write each item deliberately instead of inferring it from chat.

Why do bots get facts wrong?

Bots usually get facts wrong through staleness, not invention. The detail was true when stored and later changed. Read facts at the moment of use, treat old ones cautiously, and confirm anything consequential.

Is a phone number enough to identify someone?

No. Numbers are recycled, handsets are shared, and one business number may serve several people. Be cautious about volunteering stored details without a prompt from the customer.

What should a bot deliberately not remember?

A bot should not store sensitive information volunteered incidentally, anything the customer asked it to forget, anything stated as a one-off, and inferences you would be uncomfortable showing the customer.

Are conversation summaries safe?

Summaries are safe only with care. They lose conditions and qualifications first, which are usually what mattered. Store approvals, prices, dates and instructions as structured fields, and keep the original.

Should users be able to reset the conversation?

Yes, and the option should be discoverable. State plainly that clearing a conversation does not delete the customer's data, since a customer who assumes otherwise will be surprised later.

Does more memory make a bot better?

Only up to a point. Beyond it, answers get worse because the history contains contradictions and abandoned branches, and the privacy stakes rise with everything retained.

What should I test?

Test the second conversation. A fresh thread always works, and the problems appear on the return visit, where staleness and identity issues live.

Related reading

• Multi-stage flows and keeping state
• Data protection for a messaging bot
• The edge cases that actually matter