A customer calls an airline on Monday about a bag that never came off the belt. The agent apologizes, opens a case, and promises a callback. On Thursday the bag still has not shown up, so the customer calls again, gets a bot first, and ends up typing the flight number, the bag tag, and the whole story from scratch. The Monday case sits in the airline's system the entire time. The bot simply does not have it.
That gap is not a bug anyone forgot to fix. It is closer to how most commercial support bots are actually built. A support chatbot usually runs on top of a company's own knowledge base and a session tied to one ticket or one conversation, not a running memory of a specific customer across every contact they have ever made. The bot can sound personal while it answers a question. It is rarely designed to carry a person's history forward on its own.
What a Support Session Actually Holds
Zendesk's own developer documentation describes exactly this boundary for its AI Agents product. Session parameters, the data a bot collects while talking to a customer, are kept separate conversation by conversation: "Parameters are isolated per session," and the data stored through the API is, in the company's own words, "unique to each ongoing conversation with the bot." Nothing written during one chat shows up automatically in the next one, even for the same returning customer.
Zendesk's support documentation adds a time limit on top of that separation. A session can stay active for up to two hours, and once it times out, a new one starts and the earlier context disappears: "the system creates a new session, and the previous conversation context is lost." The article gives a concrete case: a bot sends a customer a form on Monday, the customer fills it out and returns it on Tuesday, and because the original session has already expired, the bot "no longer has the prior context" it needs to file the response correctly.
If a bot asks the same three questions you already answered an hour ago, the likely cause is not carelessness. Its memory of that conversation may have already expired on a timer running quietly in the background.
Intercom's Fin Shows What Counts as New
Intercom's Fin AI Agent is one of the more capable bots on the market, and its own page is specific about where its memory starts and stops. Fin "follows context across a full conversation," and when a human agent has to step in, Fin "hands off with the full conversation history attached," so a customer should not have to start over mid-conversation. That guarantee covers one conversation, start to finish.
Remembering a customer across separate visits, days or weeks apart, is a different capability, and Intercom treated it as one. On August 13, 2026, Intercom's changelog announced a feature under the heading "Fin now remembers past conversations," describing a bot that keeps track of what a returning customer already covered, with memory that "travels with the customer from chat to email." A feature only earns a changelog entry and a launch date if it was not already there. Cross-visit memory was the exception a vendor had to build and announce, not the default every support bot had already been running on.
Why the Bot Cannot Just Check the CRM
A reasonable question follows: if the company already has the Monday case on file, why can the Thursday bot not just look it up? Often because the chat widget on the website and the system holding the customer's full history were built by different teams, bought from different vendors, and never fully wired together, even though both sit under the same company name.
RingCentral's own analysis of this problem names the cause plainly: "systems of record remain siloed," even when the underlying software is capable enough to solve it. The piece walks through what happens at each step: a customer explains a problem, gets transferred, and "explains it again," because detail captured in one tool is "reduced, reformatted, or lost entirely" before it reaches the next one. The gap is rarely that the data does not exist somewhere inside the company. It is that nothing reliably carries it from the system that captured it to the system, or the bot, that needs it next.
The Handoff Is Where Memory Actually Dies
Even a bot built to pass its own history forward still runs into the handoff to a live person as a second, separate failure point. Twilio reports a stark number: 76% of consumers say the human agent they eventually reach has little to no context about their issue, even after they had already explained it once. Intercom's design goal for Fin, handing off "with the full conversation history attached," describes what a well-built handoff should look like. The 76% figure describes how often customers say that is not what actually happens once a person picks up the conversation.
A Reason Nobody Tells You at the Counter
Some of this is simply unfinished engineering: an old bot bolted onto older ticketing software that nobody connected properly. A second, more deliberate reason sits underneath the plumbing problem. Keeping a permanent, cross-channel memory of a specific person inside the chat layer itself means keeping more personal data, for longer, in one more place a company has to defend.
Privacy law gives that caution a name. GDPR's data minimization principle requires personal data to stay "adequate, relevant and limited to what is necessary" for the purpose it was collected for, and its storage limitation principle requires that same data to be "kept in a form which permits identification of data subjects for no longer than is necessary." A bot that forgets a customer once a ticket closes, or once a session times out, satisfies both principles without anyone having to think about it twice. A bot that remembers everything about every customer forever is a second standing dataset someone now has to justify, secure, and be ready to produce on request, on top of whatever the CRM already holds.
None of that proves any specific company chose a short memory on purpose. Most of the time, a forgetful bot is just an old one, not a cautious one. But it does mean a company that remembers less about you is not automatically the careless party. Sometimes the short memory is the deliberate choice, and the company that builds a longer one, the way Intercom shipped cross-visit memory as a dated, named feature, had to decide the convenience was worth the extra data it would now be holding.
Three Different Memories, Side by Side
| What it holds | Typical support bot | Company's backend CRM | A personal AI memory layer |
|---|---|---|---|
| Scope | One conversation or ticket, often gone after a timeout as short as two hours | Every contact a company has logged, across channels and years | What one person has told their own ChatGPT, Claude, or Gemini |
| Who it serves | The company, inside that one interaction | The company, across its full relationship with the customer | The individual, across the AI tools they personally use |
| Cross-visit memory by default? | Rarely; Intercom's Fin shipped it as a dated, named feature, not a given | Sometimes, depending on how well internal tools are connected | Yes, that is the specific point of the product |
| Can you see what it stored? | Rarely a customer-facing view | Sometimes, through a formal data-access request | Yes, built as something the person owns and can review |
| Built to act on a company's behalf? | Yes, inside the one ticket it owns | Yes, across support, billing, and sales | No, it recalls context back to the person; it does not act for a business |
What Actually Helps on the Next Call
- Keep the ticket or case number from the last contact and give it up front. It is the fastest way to point a human at whatever record survived the handoff, instead of making them search for it.
- Ask directly whether the note from your last contact is visible to the person you are speaking with now. The answer tells you whether the gap is a technical one or a policy one.
- If a bot asks the same qualifying questions twice in the same week, that usually matches the session-timeout pattern described above, not a sign that anyone ignored your last message.
- For a long-running issue, ask support to add detailed notes to your account record rather than just closing the ticket. A sparse closed ticket is easy for the next session to skip past entirely.
A ticket number said out loud does more work than frustration does. It points a human agent straight at whatever record actually survived the handoff.
None of this is a problem a personal memory tool can fix, and it would be dishonest to imply otherwise. A company's support bot forgets a customer for structural reasons: a session that expires on a timer, a CRM it was never wired into, a handoff that drops detail, and a retention policy written by a compliance team, not a product team. MemX does not touch any of that. It is not a customer-service tool, and it does not plug into an airline's chat widget or a bank's ticketing system.
What MemX (memx.app) does is a narrower, personal version of an adjacent problem. When a person explains the same project background, the same preference, or the same ongoing situation across their own ChatGPT, Claude, Gemini, and documents, MemX recalls it back to them instead of making them retype it into a fresh chat every time. It is private by architecture, built on per-user isolation and encryption at rest, and scoped to the one person using it. That is a different problem from a company remembering its customers, solved for a different party: the individual sitting on the other end of the phone, not the business they just called.
01Why do I have to repeat myself to customer service bots?
Most support bots scope their memory to one conversation or ticket, often on a timer as short as two hours, so once it expires or you switch channels, the bot starts over even if the company's own systems hold your last contact somewhere else.
02Does a company's chatbot see my full account history?
Usually not automatically. The chat widget and the backend CRM or ticketing system are often built and maintained separately, so a bot can lack access to history the company technically already has on file.
03Why does a human agent not know what I already told the bot?
The handoff between bot and human is where detail most often drops. Twilio reports that 76% of consumers say the human agent they reach has little to no context about their issue, even after explaining it to a bot first.
04Is it legal for a company to remember everything I've told its support bot forever?
It can be, but privacy law in places like the EU sets limits. GDPR's data minimization and storage limitation principles require keeping personal data only as long as it is needed, which pushes some companies toward shorter, ticket-scoped memory by design.
05Can an AI memory tool like MemX fix a company's forgetful support bot?
No. MemX is a personal memory layer for an individual's own ChatGPT, Claude, Gemini, and documents, not a customer-service system. It cannot plug into or change how an airline, bank, or SaaS support bot remembers a customer.
