One brain, many channels: shared memory across WhatsApp, Telegram and web

The shop with amnesia. Picture Sara, who sells handmade candles online. On Monday a customer called Omar messages her shop on WhatsApp and books a custom order pickup for Tuesday at three. On Tuesday morning he opens Telegram, because that's where he follows the shop, and asks to move the pickup. Sara's Telegram bot answers: hi there, how can I help, can you tell me your name? To Omar, it's one shop that suddenly lost its memory. He told the shop everything yesterday. In this lesson we fix that, so every channel talks to one brain that remembers each person, whichever app they use.

What you will learn. Here's the checklist for today. First, you'll see why building one bot per channel quietly creates three strangers who never share notes. Second, you'll learn the key idea of the whole lesson: one customer ID that links a WhatsApp number, a Telegram account and a web login to the same person. Third, you'll learn how to store memory in one place, load it before every reply, and link new accounts without mixing people up. You already have a WhatsApp agent and a Telegram bot from the last lessons, so we're wiring together pieces you've built.

Three bots, three brains. Let's see why it breaks. An agent's memory is simply saved notes, past messages and facts, that the agent reads before it answers, like a shop assistant glancing at the order book. When you build each channel as its own workflow, the WhatsApp bot keeps its own notebook, the Telegram bot keeps another, and the web bot keeps a third. Each notebook is filed under that app's chat ID, the number the app gives a conversation. So what does the Telegram bot know about a booking made on WhatsApp? Nothing at all. Same person, three folders, zero shared facts.

One brain, many doors. Here's the better design. Think of your shop with three front doors: WhatsApp, Telegram and the chat box on your website. Every message passes through one router, a small step in your workflow that works out who is talking and which app they used. Then it calls one agent, and that agent reads and writes one shared memory. Watch a message from Telegram. The router turns the sender into customer C zero four two, the agent loads that customer's history, writes a reply, and the router sends it back out through Telegram. One brain, and every door leads to it.

The identity key. The trick is a small lookup table, often called identity linking. You won't type this code; it just shows the lookup your sheet will do. Each row pairs a channel and that channel's sender ID with your own customer ID. Omar's WhatsApp number and his Telegram ID both point to C zero four two. Memory is then filed under the customer ID, never under the chat ID. When we ask about the WhatsApp number, we get Omar and his Tuesday booking. Ask about the Telegram ID, and it's the same Omar, same booking. An unknown Telegram user gets "new contact". In n8n or Make, the no-code automation tools you've been using, this table is just a Google Sheet, Airtable or database table.

Every message, the same path. Every message, from any app, now walks the same path. First it arrives. Then we normalize it, which just means converting it into one standard shape: channel, sender ID, text, and time. It's like copying orders from three different paper forms onto your own order slip, so the rest of the shop only reads one format. Next we find the customer ID in the lookup table and load that customer's memory. The agent writes its reply, and finally we send it back on the same channel, keeping the channel name from step one so nothing goes out the wrong door.

Two kinds of memory. Not all memory is the same. Short-term memory is the recent conversation, like sticky notes on your desk. Long-term memory is the customer's file card: name, current booking, whether they're a hot lead, any unpaid invoice. Why split them? A language model has a context window, the amount of text it can read in one go, like the size of a desk. Pile every old message on it and replies get slower, pricier and confused. So keep the last ten or so messages, summarize older ones into a line or two, and update the file card whenever a fact changes.

Worked example: Omar moves his pickup. Let's follow Omar. On Monday he's in a cafe and texts the shop on WhatsApp: can I pick up my order Tuesday at three? The router finds C zero four two, the agent saves the booking on his file card and confirms. On Tuesday he's at home on his laptop and writes on Telegram: can I move it to Wednesday morning? The router looks up his Telegram ID, finds the same customer ID, and opens the same notebook. The agent already knows his name and his booking, checks the shop's free slots, and asks: Wednesday at eleven works, shall I book it? Omar says yes, and the agent updates his file card and sends a new confirmation. No questions repeated.

Linking a new account safely. But how did Omar's Telegram ID get into the table in the first place? On his first Telegram message, the router found no match. So the bot asked him to share his phone number, which Telegram allows with a one-tap contact button. One small detail: apps write numbers differently, with or without the plus sign or the country code, so first rewrite every number in one format, plus sign and country code, then compare. The number matched his WhatsApp row, so we added the Telegram ID to C zero four two. On your website, the same job is done by a login, or by emailing a one-time code. If nothing matches, create a fresh customer ID and treat them as a new lead. Proof first, then link.

Common mistake: merging by name. Here's the trap that bites small businesses. To save effort, someone links accounts by display name. Then Ahmed one orders a gift box of candles on WhatsApp, Ahmed two writes on Telegram, and the agent cheerfully tells Ahmed two about Ahmed one's order, or reads out his unpaid invoice. That's a real privacy leak, and in many countries a legal problem. Names, profile photos and similar spellings are never proof. Link only when a phone number, email or one-time code matches. When in doubt, keep them separate; a repeated question costs far less than a leaked invoice.

Recap. Let's wrap up. First, file memory under your own customer ID, never under each app's chat ID, so one person stays one person. Second, send every channel through one router to one agent, normalize the message, load memory, and reply on the same channel. Third, link accounts only with proof, like a shared phone number or a one-time code. And fourth, keep short-term chat separate from the long-term file card. With one notebook behind every door, your customers feel remembered everywhere, which is exactly what keeps them coming back.

Your exercise. Now it's your turn. Create a customers table in Google Sheets or Airtable with columns for customer ID, WhatsApp number, Telegram ID, email and current booking. Add a row for yourself with your WhatsApp number and your Telegram ID under one customer ID, or, for an extra challenge, build the share-your-phone-number step from earlier so the bot links you itself. In your automation tool, point both the WhatsApp and Telegram triggers into one workflow, add a normalize step, then a lookup step on that table. Set your agent's memory session key to the customer ID instead of the chat ID. Then add a step, or give the agent a tool, that writes to the booking column whenever a booking changes. Finally, test it with your own phone: book a slot on WhatsApp, and change it on Telegram. If the agent remembers you, you're ready for MCP next lesson.