Does Semantic Kernel Remember Between Sessions? What Chat History, Agent Threads, and Memory Providers Actually Persist

No, not by itself. Inside one session, Semantic Kernel keeps the conversation in a ChatHistory object that lives in your process. When the session ends, that object is gone unless your code saved it somewhere. Semantic Kernel ships memory components you can attach to an agent thread, and it integrates with vector stores you wire up yourself, but nothing is retained across sessions by default. The persistence layer is always yours to build.

What does Semantic Kernel remember inside one session?

Short-term conversation state, and only that. Every turn, your app appends the user message and the model reply to a ChatHistory list and resends the whole list with the next call. That is how the agent "remembers" what was said two minutes ago: your code hands the history back to the model each time.

Two consequences follow from this design. First, the history is unbounded by default, so a long session keeps growing the prompt and the bill with it. Semantic Kernel includes chat-history reducers that truncate old messages or summarize them, which is the sanctioned way to keep the window under control. Second, the history lives in your application's memory. Scale out to a second server, restart the process, or close the app, and the list is gone. It was never stored anywhere durable.

What happens to memory when the session ends?

Nothing automatic. There is no built-in session store, no user profile that accumulates, no record of what the agent learned about the user that carries into the next conversation. If you want the agent to greet a returning user with knowledge of the last session, you serialize the ChatHistory to JSON yourself and store it in a database or cache keyed by conversation ID, then reload it when the user comes back. The framework gives you the object; the saving and loading are your code.

Older Semantic Kernel versions shipped higher-level abstractions for this, like the SemanticTextMemory APIs. Those are legacy now and the current guidance is to avoid them in new code. The modern surface is lower level: chat history for the short term, vector stores for retrieval, and agent-thread memory providers for extracted memories.

What are Semantic Kernel's memory providers, and what do they actually do?

The Agent Framework supports components that attach to an AgentThread, pull memories out of the messages added to that thread, and hand those memories back to the agent when needed. Microsoft documents two of them, and both are marked experimental.

The WhiteboardProvider is the short-term one. It processes each message and extracts requirements, proposals, decisions, and actions onto a "whiteboard" that travels with the thread. Its real job is surviving truncation: when you cut the chat history down to fit the context window, the whiteboard keeps the distilled version of what mattered. You can cap how many messages it retains, and less valuable entries get removed first.

The Mem0Provider is the long-term one. It sends every thread message to the Mem0 service, which extracts memories, and on each invocation it queries Mem0 for memories matching the current request and injects them into the agent's context. The scoping is the important part: configure it with a user ID and memories persist across threads for that user; configure it with a thread ID and memories stay attached to that single thread. You can also combine both providers, so one agent gets whiteboard short-term context plus Mem0 long-term recall.

Notice the pattern. In every case, the memory lives outside Semantic Kernel: in the Mem0 service, in a vector store you configured, in a database you wrote. The framework orchestrates the handoff. It does not operate the storage.

How do you make a Semantic Kernel agent remember between sessions?

There are four pieces, and you need all four for a production agent:

1. Persist the chat history yourself. Serialize ChatHistory to JSON and store it keyed by conversation or user ID in a database or cache. Reload it at the start of each session. Do not keep it only in server memory if you scale out or restart.
2. Bound the history with reducers. Truncate or summarize old turns so long sessions do not blow the context window or the token budget. The whiteboard provider can carry the distilled decisions so truncation does not lose the plot.
3. Attach memory providers to the agent thread. Use the whiteboard for short-term extracted context within and across the turns of a thread, and a provider like Mem0 with a user-level scope for memories that should follow the user across threads and sessions.
4. Wire your own long-term store. For semantic retrieval over past interactions, documents, or user facts, connect a vector store and handle the write path (what gets stored, scoped to which user) and the read path (what gets injected per request) in your application code.

If you are building scheduled agents on top of Semantic Kernel, a cron job that runs every morning, step one is the one people skip. A scheduled run is a brand-new session every time. Without persisted history keyed to something stable, each run wakes up knowing nothing about the previous one, no matter which memory providers you attached, because the providers' inputs start empty too.

What if you do not want to operate memory infrastructure for every agent you ship?

This is where hosted memory services earn their place. The dividing line in agent memory is not who writes the agent, it is who operates the memory. Embedded libraries mean you run the storage, the retrieval, the scoping, and the maintenance. A hosted layer means the agent gets memory without any of that infrastructure on your side.

Vilix AI is built for exactly that second option. A built agent connects with an API key as a Bearer header to https://api.vilix.ai/mcp and gets full memory with zero memory infrastructure: it saves turns with save_turn, loads relevant context with get_context, and retrieval combines semantic search with keyword matching so exact strings like order IDs and policy names are found literally. Memory stays isolated per user, and everything is exportable or deletable at any time. Your Semantic Kernel agent keeps its framework and its tools; the part that remembers simply stops being something you have to build and run.

The short version

Semantic Kernel remembers the current conversation while your process is alive and forgets everything the moment it is not. Cross-session memory comes from four things you build: persisted chat history, bounded context, thread memory providers, and your own vector store. Know that going in, wire all four, and the "my agent forgot everything overnight" bug never ships.