How Do You Give a Discord AI Agent Memory Between Conversations?

You give a Discord AI agent memory between conversations by storing every message turn in a memory store keyed by the Discord user ID, loading that user's relevant history before each model call, and saving the new exchange back after the reply. Discord itself gives your bot no memory: each message arrives as a separate event, and the model only sees what your code sends in that one call.

Why does a Discord AI agent forget everything?

Three separate layers all start blank, and none of them is broken.

First, Discord delivers each message to your bot as its own event over the Gateway connection or as an interaction. There is no running conversation process on your side that stays alive between messages. Your handler wakes up, receives one message, and finishes.

Second, the model call is stateless. A chat completion only contains the messages you put in that request. If you send only the new message, the model has no way to know the same person explained their project in this server last week.

Third, the quick fixes most builders reach for are temporary. The common tutorial pattern is a dictionary in the bot process, keyed by guild, channel, and user. It works until the process restarts, redeploys, or scales to a second instance, and then every user's history disappears at the same moment.

Discord can let a bot re-read recent messages in a channel, with the right permissions and the Message Content Intent enabled. That is channel history, not agent memory. It does not follow a user into DMs, into another channel, or into another server, and it holds what a whole channel said, not what one person decided with your agent.

What should a Discord agent actually remember?

Not every word forever, and not nothing. A useful memory for a Discord agent holds four kinds of information:

1. Identity facts: the user's name, role in the server, language, and account details, keyed by user ID.
2. Decisions already made: a refund already offered, a moderation call already made, a plan already agreed.
3. Open loops: the question the user was last asked, the file they still owe you, the task still running for them.
4. The full conversation history: what was actually said in earlier conversations, so a later session can revisit the real exchange instead of a shortened note about it.

Items 1 to 3 stop repeat questions. Item 4 stops contradictions, because the agent can check what a previous session actually promised.

How do you scope memory across servers, channels, and threads?

A DM is the simple case: one user ID, one person, one memory. Servers need one extra decision.

Keyed by channel ID alone, a busy channel shares one history among everyone posting in it. That is usually wrong for personal help: one member's case bleeds into another member's next question. Keyed by user ID alone, the opposite problem appears: context from a private support server follows the user into a public community channel where it does not belong.

The working split is two records. A per-user record holds facts about the person and follows them across channels and servers. A per-conversation record holds the thread of one case, keyed by guild ID plus channel ID plus user ID, with the thread ID added when each Discord thread should stay its own conversation. That split keeps a support case private to its server while still letting the agent know who it is talking to in a new channel.

How do you add memory to a Discord agent, step by step?

1. Key everything by user ID. The user ID arrives in every message payload and stays stable across servers, channels, and DMs. Every stored turn, fact, and decision hangs off that key, with guild and channel IDs added where a conversation must stay inside one server.
2. Save each turn as it happens. Store the inbound message and your agent's reply, in order, before you consider the turn done.
3. Load memory before the model reasons. At the start of each turn, retrieve the history and facts that are relevant to this user and this message, and put them in the model call. Load relevant context, not the whole archive.
4. Save the outcome, not just the reply. After the agent acts, write back what it decided and what is still open, so the next conversation starts from the result of this one.
5. Use a store that survives restarts. Move the memory out of the bot process and into a store that is still there after a redeploy, or the first restart erases every conversation at once.
6. Keep per-person records apart in shared channels. In a channel where many members talk to the agent, retrieve by user first and channel second, so one member never receives context that belongs to another.
7. Repeat the same load and save in every tool. If a dashboard agent, a scheduled follow-up agent, and the Discord agent all serve the same user, they need to read and write the same memory, or each one keeps a private version of that user.

Steps 1 to 6 are the pattern behind every do-it-yourself version of this setup, whether the store is a small database behind a Python bot or a hosted memory service behind a no-code agent. The pattern works. The work is in running it: one store per agent, retrieval you build yourself, and no connection to the memory your other tools already hold.

Where does Vilix AI fit in a Discord agent setup?

Vilix AI is a shared memory layer your agent connects to instead of a store you build and maintain yourself. It is cloud-hosted, so there is zero infrastructure to deploy or manage next to your bot server. A headless agent connects with an API key as a Bearer header to https://api.vilix.ai/mcp, and interactive tools connect to the same account over MCP with OAuth.

The workflow matches the steps above. Before the model reasons, the agent calls get_context and loads the relevant saved context for that user. After it replies, it calls save_turn and saves the full exchange back. Retrieval is semantic and keyword-based at the same time, so recall finds what a conversation meant and still matches exact strings such as order IDs and usernames literally. Vilix AI stores full conversation history, not just extracted facts, so next week's conversation can revisit what was actually said this week.

Because the memory lives on the account, not inside the bot process, the same user history is available to your other connected tools: Claude, Codex, Cursor, OpenClaw, Hermes, and any other MCP-compatible client on the same account. A decision made in Discord is there when the work continues in a coding tool, and a decision made in a coding tool is there when the user asks about it in Discord. You can list, edit, and delete stored memories, export everything in a portable format at any time, or wipe the account instantly.

Start on the free plan, or run the 7-day free trial of full Pro with no credit card.

Frequently asked questions

Does Discord itself store memory for my AI agent?

No. Discord keeps messages in channels and delivers each new message to your bot as an event, but nothing loads earlier conversations into your model call. A bot can re-read recent channel messages with the right permissions, and that is still channel history, not per-user memory. Memory is a layer you add on your side of the message handler.

What is the simplest key to store Discord memory against?

The user ID. It arrives in every payload, it stays stable across conversations, and it follows the person across channels and servers. Add the guild and channel IDs when a conversation must stay inside one server, and add the thread ID when each thread should keep its own history.

Can one memory serve Discord and my other AI tools?

Yes, if the memory lives outside any single tool. A store inside one bot process or one automation platform is only readable by that process or platform. A shared memory layer connected over MCP can be read and written by your Discord agent and by the other AI tools on your account.