How Do You Give a Microsoft Teams AI Agent Memory Between Conversations?

You give a Microsoft Teams AI agent memory between conversations by saving every turn to a store keyed by the Teams user ID, loading the relevant part of that history before each model call, and writing the new exchange and its outcome back after the reply. Teams delivers each message as a separate activity to a stateless bot, so nothing carries over unless your code saves it and loads it again.

Why does a Teams AI agent forget between conversations?

Microsoft states the root cause plainly in its bot documentation: a bot is inherently stateless, and a different instance of your bot may handle the next turn. Three layers follow from that design.

First, the delivery layer. A message in Teams reaches your agent as one activity, with IDs for the user, the conversation, and the channel. Your handler runs for that activity and ends. There is no live conversation process waiting for the next message.

Second, the model layer. A model call contains only the messages your code puts in it. Send only the new message and the model has no record of what the same person settled with your agent in a channel thread last week.

Third, the default storage layer. The common starting points keep state in the bot process: the Bot Framework MemoryStorage class, or an in-memory chat history provider in the newer agent frameworks. Both work in a demo and both empty on restart, redeploy, or scale-out. Microsoft labels the in-memory option as local testing storage for exactly that reason.

Teams itself stores chat messages, and a bot can read channel history within its permissions. That history is scoped to one conversation in one place. It does not follow a person from a channel thread into a 1:1 chat, and it records what people said, not what your agent decided, promised, or left open.

What should a Teams agent actually remember?

Four kinds of information cover almost every repeat question and contradiction:

1. Identity facts: the person's name, role, team, language, and preferences, keyed by user ID.
2. Decisions already made: the ticket already escalated, the approval already given, the answer the team already agreed on.
3. Open loops: the form still half finished, the owner still unassigned, the question your agent asked that nobody has answered yet.
4. The full conversation history: the actual earlier exchange, so a later conversation can check what was said instead of working from a short note about it.

The first three stop your agent asking for the same details twice. The fourth stops it contradicting itself, because the record holds the real words from the earlier conversation.

How do 1:1 chats, group chats, and channel threads change the scoping?

Teams gives one person several separate conversation IDs, and the scoping decision decides whether memory helps or leaks.

A 1:1 chat is its own conversation. A group chat is another one, shared by its members. A channel conversation belongs to a team and a channel, and each thread inside it is a discussion the whole channel can read.

Key everything by conversation ID alone and the agent knows a thread deeply while knowing the person in it not at all: move to a DM and the same employee starts over. Key everything by user ID alone and the opposite problem appears: details from a private HR chat can surface inside a public channel thread.

The working split is two records, which mirrors the state scopes Microsoft itself documents. A per-user record holds facts about the person and follows them across conversations on the channel. A per-conversation record holds one case or thread, keyed by conversation ID plus user ID, so group and channel discussions stay inside their own boundary. Tenant and team IDs belong on the record when one deployment serves more than one organization or team.

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

1. Key memory by user ID first. The sender ID arrives in every activity and stays stable for that person in your deployment. Hang facts and decisions off it, and add conversation, team, and tenant IDs where a record must stay in one place.
2. Save each turn as it completes. Store the incoming message and the agent reply together, in order, before the turn counts as done.
3. Load relevant memory before the model reasons. Retrieve the history and facts that match this person and this message, then build the model call from that selection plus the new message. Load the relevant part, not the whole archive.
4. Save the outcome, not only the reply. Write back what the agent decided and what is still open, so the next conversation starts from the result of this one.
5. Move state out of the process. In-memory storage is a testing tool. Production memory belongs in a store that survives restarts and is shared by every bot instance.
6. Keep private conversations private. Retrieve per-user records only for that user, even inside group chats and channel threads where many people talk to the same agent.
7. Use the same memory in every surface. An agent that answers in Teams, a scheduled agent that follows up overnight, and a dashboard agent that reviews the case should read and write one memory, or each one keeps its own partial version of the person.

Steps 1 to 6 are the pattern behind every do-it-yourself Teams setup, from Bot Framework user and conversation state backed by blob or database storage, to a custom history provider behind a Teams SDK agent. The pattern works. The ongoing work is operating it: storage you run, retrieval you build, and a memory no other tool on your account can read.

Where does Vilix AI fit in a Microsoft Teams agent setup?

Vilix AI is a shared memory layer your agent connects to instead of a state store you build and maintain yourself. It is cloud-hosted, so there is zero infrastructure to deploy or manage next to your bot. 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 person. 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 ticket numbers and case IDs literally. Vilix AI stores full conversation history, not just extracted facts, so next month's conversation can revisit what was actually agreed this month.

Because the memory lives on the account, not inside the bot process, the same history is available to the other tools connected to that account: Claude, Codex, Cursor, OpenClaw, Hermes, and any other MCP-compatible client. A decision reached in a Teams thread is on record when the work continues in a coding tool, and a decision made there is on record when the person asks about it in Teams. 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 Microsoft Teams store memory for my AI agent?

No. Teams stores messages and delivers each one to your bot as an activity, but nothing loads earlier conversations into your model call. Bot Framework state and agent-framework history providers are layers you configure on your side, and their in-memory defaults are cleared on restart. Memory between conversations is storage and retrieval your agent runs on every turn.

What is the difference between user state and conversation state in Teams?

User state follows one person across their conversations with your bot on that channel, which makes it the right scope for identity facts and preferences. Conversation state belongs to one specific conversation, such as one group chat or channel thread, which makes it the right scope for a single case. Working Teams agents use both: per-user records for the person, per-conversation records for the case.

Can one memory serve a Teams agent and my other AI tools?

Yes, if the memory lives outside any single tool. State stored inside one bot or one automation platform is only readable there. A shared memory layer connected over MCP can be read and written by your Teams agent and by the other AI tools on your account, so every surface works from the same record.