Home » Memory-Powered Customer Service » Build a Support Bot That Remembers

How to Build a Support Bot That Remembers

Building a support bot that remembers customers requires three additions to a standard LLM chatbot: identity resolution that maps conversations to customer profiles, memory storage that captures key information after each interaction, and context retrieval that injects relevant history into new conversations. The result is a bot that knows who it is talking to, what has been discussed before, and what solutions have already been tried.

Before You Start

You need a working LLM-based chatbot, meaning any system that sends user messages to an LLM API and returns responses. The specific framework does not matter. This guide works with custom implementations, LangChain, LlamaIndex, or any other orchestration layer. You also need a memory API that supports storing and retrieving memories by customer ID. Adaptive Recall provides this through its MCP tools or REST API, but the architecture applies to any persistent memory backend.

Your chatbot currently handles each conversation in isolation. Messages go in, responses come out, and nothing persists after the session ends. By the end of this guide, your bot will store a summary of each conversation, retrieve relevant history at the start of new conversations, and use that history to provide personalized, context-aware support.

Step-by-Step Implementation

Step 1: Set up customer identity resolution.
Every memory needs to be linked to a specific customer. Before your bot can remember anyone, it needs to know who it is talking to. The simplest approach is to use whatever authentication your support system already has. If customers log in before chatting, use their user ID. If they provide an email or account number, use that as the identity key. The critical requirement is consistency: the same customer must resolve to the same identity across sessions and channels.
def resolve_customer_id(session_context): if session_context.get('authenticated_user_id'): return session_context['authenticated_user_id'] if session_context.get('email'): return lookup_customer_by_email(session_context['email']) if session_context.get('account_number'): return lookup_customer_by_account(session_context['account_number']) return None # anonymous session, no memory possible

For anonymous channels like public chat widgets, memory only becomes available once the customer identifies themselves. You can prompt for identification early in the conversation ("Can I get your email or account number so I can pull up your history?") or let the conversation proceed without memory until the customer provides identifying information naturally.

Step 2: Store interaction memories after each conversation.
When a conversation ends (or at natural breakpoints during long conversations), extract the key information and store it as a memory linked to the customer ID. Do not store the raw conversation transcript, which is too verbose and retrieves poorly. Instead, extract a structured summary that captures what the customer asked about, what the resolution was, any new information learned about the customer, and any preferences or sentiment signals.
# After conversation ends, store the summary memory_content = { "text": "Customer contacted about failed API integration with " "their Node.js application. The issue was an expired API " "key. Resolved by generating a new key and updating " "their environment variables. Customer is technically " "proficient and prefers direct, code-level explanations.", "metadata": { "customer_id": customer_id, "channel": "live_chat", "topic": "api_integration", "resolution": "resolved", "sentiment": "positive_after_resolution", "timestamp": "2026-05-12T14:30:00Z" } } memory_api.store(memory_content)

The metadata is important for retrieval. Topic tags let the system find relevant past interactions when the customer returns with a related issue. Resolution status helps the system know whether a past issue was actually solved. Sentiment tracking lets the system recognize when a customer has been through multiple frustrating interactions and adjust its tone accordingly.

Step 3: Recall context at conversation start.
When a new conversation begins and the customer has been identified, query the memory store for relevant context before the first response. The query should retrieve recent interactions, open issues, and any stored preferences. Use the customer ID as a filter and let cognitive scoring rank the results by recency and relevance.
# At conversation start, retrieve customer context def get_customer_context(customer_id, current_message): memories = memory_api.recall( query=current_message, filter={"customer_id": customer_id}, limit=10 ) return format_context(memories)

The current message serves as the query for semantic relevance. If the customer opens with "I am having the same API problem again," the retrieval will prioritize past API-related memories. If they open with something unrelated, the retrieval still returns recent interactions ranked by recency, giving the bot general context about the customer.

Step 4: Inject context into the system prompt.
Format the retrieved memories as structured context in the LLM system prompt. The system prompt tells the AI what it knows about this customer, giving it the background needed to personalize its responses and avoid asking for information it already has.
system_prompt = f"""You are a support assistant for Acme Corp. CUSTOMER CONTEXT (from previous interactions): {formatted_customer_context} INSTRUCTIONS: - Use the customer context to personalize your responses - Do not ask for information you already have from context - Reference past interactions naturally when relevant - If the customer had a previous issue that seems related, mention it - Match the communication style the customer prefers """

Keep the context section concise. Ten well-structured memory summaries use roughly 500 to 1,000 tokens, which is a small fraction of the context window but provides significant personalization value. If the customer has extensive history, prioritize the most recent and most relevant memories rather than dumping everything into the prompt.

Step 5: Update memories during the conversation.
Do not wait until the conversation ends to store memories. As the conversation progresses, store new observations that would be valuable in future interactions. If the customer mentions they switched to a new technology stack, store that immediately. If they express a strong preference, store it. If a troubleshooting step succeeds or fails, store the result.
# During conversation, when significant information is shared if detected_new_info: memory_api.store({ "text": "Customer migrated from AWS to GCP last month. " "All infrastructure references should use GCP " "terminology and services.", "metadata": { "customer_id": customer_id, "type": "semantic", "topic": "infrastructure", "confidence": "high" } })

Be selective about what you store mid-conversation. Every memory adds to the retrieval pool, and storing too many low-value observations dilutes retrieval quality. Focus on information that will change how future interactions should be handled: factual changes to the customer's environment, newly discovered preferences, and resolution outcomes for specific issues.

Step 6: Consolidate memories periodically.
Over time, a customer accumulates many memories from multiple interactions. Without consolidation, retrieval slows down and results become noisy because old, superseded information competes with current information. Run consolidation periodically (daily or weekly, depending on interaction volume) to merge redundant memories, update outdated information, and maintain retrieval quality.
# Periodic consolidation job for customer_id in active_customers: memories = memory_api.recall( query="*", filter={"customer_id": customer_id}, limit=100 ) # The reflect tool consolidates related memories memory_api.reflect( filter={"customer_id": customer_id}, strategy="merge_by_topic" )

Consolidation is what separates a production memory system from a prototype. Without it, your bot's knowledge of long-term customers degrades over time as the signal-to-noise ratio in their memory profile worsens. With consolidation, the system maintains a clean, current understanding of each customer regardless of how many interactions they have had.

Testing Your Implementation

Test memory-powered support with a three-interaction sequence. First, contact your bot as a new customer and describe a specific issue with specific details about your setup. Second, start a new conversation as the same customer and see if the bot references your previous interaction without being prompted. It should greet you with awareness of your history and not ask for information it already has. Third, contact the bot about a related but different issue and verify that it connects the context from your first interaction to the new problem.

If the bot does not recall previous interactions, check identity resolution first, then verify that memories are being stored with the correct customer ID, then confirm that retrieval is filtering by customer ID correctly. The most common failure point is identity resolution: the bot stores memories correctly but cannot link new conversations to existing customer profiles.

Give your support bot a memory that learns from every customer interaction. Adaptive Recall handles storage, retrieval, and consolidation so you focus on the customer experience.

Start Building Free

Related Articles