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

A bot that forgets what you said two messages ago is infuriating. A bot that remembers something you mentioned eight months ago, unprompted, is unsettling. Somewhere between those is a system that behaves like a competent member of staff, and getting there is a question about what to keep rather than a question about how much.

The useful distinction is between two completely different things that both get called memory. One is the thread of the conversation happening now. The other is what you know about this 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

Two things called memory

Conversation memory is the last stretch of the current exchange. It exists so the bot can resolve "yes", "the second one" and "no, the other date" without asking again. It is short-lived by design, it does not need to be accurate about the world, and losing it costs nothing beyond the current conversation.

The customer record is what your business knows: who they are, what you did for them, what they own, what they agreed. It is long-lived, it has to be accurate, and it belongs in your systems rather than in a chat history.

Conflating the two produces both failure modes at once. A bot relying on conversation history for facts about the customer will be confidently wrong about anything that has changed. A bot with no conversation memory will ask somebody their name three times in four minutes.

So the design rule is simple: the conversation resolves references, the record supplies facts.

The conversation, and how much of it to carry

Longer is not better, for three separate reasons.

Cost and latency. More history is 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 will sometimes surface the wrong version.

Irrelevance. A message from three weeks ago in the same thread is usually about something else entirely.

Two things work better than a fixed message count. Bound it by time as well as by 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 somebody can say "actually, make it Thursday" and be understood. If that works, the window is long enough.

The record, and what belongs in it

Everything the bot needs to be correct about, written deliberately rather than inferred.

Identity, as far as you have verified it.

What you have done for them, and when.

What they own or use, which for most trades is the thing that makes the conversation useful.

What they have agreed, including anything they declined and anything they asked you not to do.

Their preferences, where they have stated them: channel, times, how they want to be addressed.

Their consent position, and what it covers.

Each of those should be written at a moment you can point to, by a process you can describe. A record assembled by a model reading old conversations is a record you cannot defend, and the first time it is wrong about something consequential you will not know why.

Staleness is the main failure

Almost every embarrassing memory failure is a stale fact confidently asserted.

Somebody's appointment moved. They sold the car. The address is old. They asked you to stop contacting them about something and the system remembers a preference from before that. In each case the bot is not hallucinating; it is remembering accurately from a snapshot that has expired.

Three defences. Read facts at the moment you need them rather than carrying them through a conversation, since something may have changed between the first message and the fifth. Give facts a sense of age, and be more cautious with older ones. And confirm rather than assert anything consequential: "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

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: 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 your WhatsApp Business Platform account, so facts come from the record rather than from the thread.
4. Describe the exceptions: a returning customer after a long gap, somebody whose details have changed, a shared number, anyone who has asked you to forget something.
5. Test the second conversation, not the first. Everything works on a fresh thread and the problems all appear on the return visit.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Keeping people apart

Memory has to be scoped to a person, and phone numbers are a weaker identifier than they look.

Numbers get recycled. Couples share a handset. A business number is used by several staff. A parent messages about a child's appointment. In each case the conversation history attached to that number belongs to more than one person, and a bot that greets whoever messages with the last person's details has leaked something.

Practical handling: keep memory per conversation thread rather than per human where you cannot tell them apart, be careful about volunteering stored details unprompted, and where identity matters, confirm rather than assume. The cost of asking is a line of text. The cost of assuming is telling somebody else's partner about their appointment.

When remembering is the wrong thing to do

Not everything a customer says should be kept, and building the reflex to discard is as important as building the ability to store.

Anything sensitive that was incidental. Somebody explaining they cannot attend because of a hospital appointment has told you something you did not ask for and should not retain.

Anything they asked you to forget. Acting on that promptly and completely is both a legal matter and a trust one.

Anything stated as temporary. "Use my mum's address this once" is not a change of address, and systems that helpfully update the record cause real problems.

Anything inferred that you would not say to their face. If it would be uncomfortable to read aloud, it should not be stored as a fact about somebody.

That last test is a good one generally. A record you would be embarrassed to show the customer is a record you should not be keeping.

Summaries, and what they quietly lose

Compressing a long conversation into a summary is a reasonable technique and it has a specific hazard: a summary is a lossy, confident reconstruction, and the loss is invisible afterwards.

Conditions and qualifications go first. "Customer approved the work" is a fine summary of an exchange where the customer approved the work subject to the price not exceeding a figure, and the qualification is precisely the part that mattered.

Two rules. Never summarise anything that functions as a commitment: approvals, prices, agreed dates and instructions get stored as structured fields, verbatim, not as prose. And keep the original alongside the summary, because the day the summary is wrong is the day somebody needs the original.

Starting again

Give people a way to clear the conversation and start fresh, and make it discoverable.

It helps in three situations: a conversation that has gone wrong and is compounding, a customer switching to a genuinely different topic, and somebody who simply wants the bot to stop referring to earlier messages.

Say plainly what it does. Clearing a conversation is not the same as deleting their data, and a customer who thinks they have erased their record will be surprised later. If they want the second, that is a different request and it goes to a person.

Making it survive

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 rather than asserting it.

Apply retention to conversation history as well as to records.

Test returning customers regularly, since that is where staleness shows.

Limits worth knowing about

Longer context is not better memory, and past a point it makes answers worse rather than better.

Phone numbers identify accounts rather than people.

Summaries lose conditions, which are usually the important part.

A model can be confidently wrong about its own history, so anything it says about what was agreed needs checking against the record.

More memory raises the privacy stakes, since everything remembered is something you hold and must account for.

What to build first

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

Two habits make the difference. Confirm consequential details out loud instead of asserting them, because one line of text prevents the entire category of stale-fact errors. And test the second conversation rather than the first, since a fresh thread always works and the return visit is where everything goes wrong.

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 record is what your business knows and has to be accurate. The conversation resolves references; the record supplies facts.

How much conversation history should be carried?

Enough that somebody can say "actually, make it Thursday" and be understood. Bound it by time and topic as well as by length, since more history costs latency and introduces contradictions.

What should go in the customer record?

Identity as far as verified, what you have done, what they own, what they agreed or declined, stated preferences, and their consent position. Each written deliberately rather than inferred.

Why do bots get facts wrong?

Usually staleness rather than invention. The detail was true when it was stored and something changed. Read facts when you need them, treat old ones cautiously, and confirm anything consequential.

Is a phone number enough to identify someone?

No. Numbers get recycled, handsets are shared, and one business number may be used by several people. Be cautious about volunteering stored details unprompted.

What should a bot deliberately not remember?

Sensitive information volunteered incidentally, anything somebody asked you to forget, anything stated as a one-off, and inferences you would be uncomfortable showing the customer.

Are conversation summaries safe?

Only with care. Summaries 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 it should be discoverable. Say plainly that clearing a conversation is not the same as deleting their data, since a customer who assumes otherwise will be surprised later.

Does more memory make a bot better?

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?

The second conversation. A fresh thread always works; 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