Does Microsoft Agent Framework Remember Between Sessions? Threads, Message Stores, and What Survives

Does Microsoft Agent Framework Remember Between Sessions? Threads, Message Stores, and What Survives

Short answer: yes, inside one running process. A thread carries your conversation across turns without any extra code. Restart the process and that thread is gone, unless you wired up persistent storage. Microsoft Agent Framework gives you the memory patterns, in-memory threads, persistent message stores, and external dynamic memory, but the database underneath is always your decision.

What a thread actually remembers

The basic building block is the thread. You create one, pass it to each run, and the framework keeps the conversation going:

thread = agent.get_new_thread()
first = await agent.run("My database is Postgres.", thread=thread)
second = await agent.run("What database do I use?", thread=thread)

The second run sees the first. That part works exactly the way you hope: no manual message juggling, no replay code. Microsoft's own docs describe the thread as the session container that persists conversation history across turns.

But notice what a thread is not. It is runtime state. It lives in your process's memory. If your agent runs on a schedule, every run is a new process, and a new process means a new thread with nothing in it. Your Monday run and your Tuesday run are strangers to each other.

What survives a restart: persistent message stores

To carry history across sessions, the framework offers persistent messages. You define a chat_message_store_factory that hands the agent a message store, and conversation history gets saved outside the process so a later session can load it back.

This is where Microsoft's own design guidance matters. Their chat-history article lays out two patterns. In service-managed storage, the AI provider keeps the conversation on its servers and your thread holds only a reference. In client-managed storage, your application keeps the full history and sends the relevant parts with each request. The framework supports both, but it does not pick for you. You choose the database, the retention policy, and what happens when history grows past the context window.

That last part is the real work. A transcript grows with every turn. Send the whole thing every time and token costs climb, latency climbs, and the model starts reasoning worse, not better. Persistence without a compaction plan is just expensive remembering.

What about knowledge, not just transcripts?

Threads and message stores replay conversations. They do not distill what was learned. Your agent does not wake up knowing your preferences, your customers, or what worked last week, unless something else puts that knowledge in front of it.

Microsoft Agent Framework handles this with dynamic memory: context providers that inject memories before a run starts. The documented example is a Mem0 provider, which pulls facts from an external memory service and hands them to the agent as context. The framework points outward by design. The long-term knowledge layer is a separate service you choose, configure, and pay for. The framework orchestrates; it does not remember for you.

The newest piece: vector transcript stores

Recently the framework added an experimental vector history provider that tries to solve the token-bloat problem. It saves the full conversation transcript into a vector collection, keyed by application, tenant, agent, and session identifiers, so different customers' histories never collide. On each turn it loads only a compacted window of recent messages, plus a search tool the agent can use to pull specific older turns on demand.

This is the closest the framework gets to real memory infrastructure. It acknowledges the two hard problems: transcripts are too big to replay whole, and multi-tenant agents must never leak one customer's history into another's. But it is experimental, the scoping identifiers prevent accidental overlap only, and your application still owns access control. And it is still a transcript: a searchable record of what was said, not a knowledge base of what was learned.

How to give an Agent Framework agent memory that survives a restart

Here is the honest recipe, in order:

1. Decide where history lives: service-managed (the provider keeps it, simpler, provider lock-in) or client-managed (you keep it, full control, you own compaction).
2. Wire a chat message store factory so threads serialize to your database instead of dying with the process.
3. Resume by thread or session id in each new run instead of creating a fresh thread every time.
4. Add a dynamic memory provider, like the Mem0 integration, for facts and preferences that should outlive any single transcript.
5. Scope every store by tenant and user id from day one. Multi-customer memory without strict boundaries is a data leak waiting for its first bad query.

Where this leaves scheduled agents

Walk through the cron scenario: your agent runs every morning, researches a topic, writes a briefing. Monday's process creates a thread, does the work, exits. Tuesday's process starts cold. Even with a persistent message store wired in, what Tuesday gets is a replay of Monday's transcript, not a summary of what Monday learned. The prospect who said "call back in Q4" is in there somewhere, buried in turn 47, and nothing in the framework surfaces it as a fact.

That is the gap Vilix AI is built for. It is cloud-hosted with zero infrastructure to manage, so there is no per-machine database to keep alive. The same memory follows your agents everywhere over MCP: your scheduled workflow, your coding tools, your browser agents, all reading and writing one shared store instead of each runtime keeping its own transcript. 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 keeps full conversation history, not just distilled facts, and retrieval is semantic plus keyword, so the fact from turn 47 surfaces when Tuesday's run needs it. Free forever, with a 7-day Pro trial that needs no credit card, and you can export or delete everything anytime.

The framework's thread is a good session. It was never meant to be your memory. The difference matters most at 7 AM, when the schedule fires and nobody is awake to re-brief the agent.