Does Rasa Remember Between Runs? The Tracker Store, Sessions, and the Blank-Start Trap

Rasa is the veteran of the open-source conversational AI world. If you are building an assistant that runs on your own infrastructure, there is a good chance Rasa is on your shortlist. And Rasa has a genuine memory system: every conversation is recorded as a stream of events in something called the tracker, and that tracker can be persisted in a database. So when you point a scheduled job at Rasa, the question feels settled in advance. Of course it remembers.

The short answer is that Rasa remembers the conversation, but it does not remember the run. It remembers the tracker you point it at. It does not decide which tracker your automation should open, and the default configuration forgets everything the moment the server restarts. For scheduled agents, those two details are the whole game.

The tracker is real memory

Rasa models a conversation as a DialogueStateTracker: a chronological stream of events. Every user message (UserUttered), every bot reply (BotUttered), every action executed, every slot filled gets appended as an event with full context. Custom actions can read the whole thing through the Tracker object, so an action can look at tracker.events and see everything that happened in that conversation, or read tracker.slots for the key data points collected along the way. Within one conversation, this is honest, complete recall. Rasa does not summarize your history away.

That tracker is keyed by a single identifier: the sender_id. One conversation, one sender_id, one tracker. Two different sender_id values mean two completely separate trackers with no shared state.

The default tracker store forgets everything on restart

Trackers are persisted by a component called the tracker store. And here is the first trap: the default is InMemoryTrackerStore. It keeps every conversation in process memory, and the entire history is lost when the Rasa server restarts. That is fine for development. In production, it means a routine deploy, a container restart, or a crash wipes every active conversation your users were having.

Rasa gives you the escape hatch in endpoints.yml: SQLTrackerStore (PostgreSQL, MySQL), Redis, MongoDB, DynamoDB. Configuring one is a few lines, and it is non-negotiable for anything real. But notice what this buys you: durable storage of past conversations. It does not buy you an agent that wakes up knowing what it was doing. Storage and recall are different problems.

Sessions are not conversations

This is the part that bites automation builders. Rasa distinguishes a conversation from a session. A conversation is the whole contained stream of events for one sender_id. A session is a bounded slice of that conversation, usually one continuous interaction window. A conversation can contain many sessions over its lifetime.

Sessions start and end on system rules, not on your schedule:

• A session begins when a SessionStarted event fires, when a message arrives with a brand-new sender_id, or when a message hits an inactive tracker.
• A session ends when an inactivity timer fires (ConversationInactive) or a SessionEnded event is emitted.

A new session can reset the assistant's state depending on your configuration. Slots may or may not carry over. So even inside the same conversation, a run that starts after a long idle gap can behave like a fresh start. The docs spell out the design intent: "new conversation" is the experience you design for the user, while "new session" is the boundary Rasa uses under the hood. Your scheduled job lives entirely under the hood.

Where scheduled runs go wrong

Picture the classic setup: a cron job that wakes up every night, calls Rasa's HTTP API to ask the assistant a question on your behalf, and processes the answer. Each of those calls arrives with a fresh sender_id unless you deliberately reuse one. A fresh sender_id means a brand-new tracker with zero events. The assistant has no record of last night's run, no record of the slots it filled yesterday, no record of what failed. It starts blind, every single night, while your tracker store quietly fills with hundreds of orphaned single-message conversations.

The same thing happens inside long-lived setups. Your assistant talks to a user on Monday, the session times out, and your Tuesday scheduled summary job opens the tracker and finds a session boundary between itself and the context it needs. The events are all there in the database. The agent just does not know it should read them.

Making Rasa remember the way an automation needs

None of this is a flaw in Rasa. It is a conversational framework behaving exactly like one. But if your automation needs continuity between runs, you have to build the continuity yourself:

1. Use a persistent tracker store. SQL or Redis via endpoints.yml. The in-memory default is a development convenience that will delete your history on the first restart.
2. Stabilize the sender_id. Give your scheduled job a fixed sender_id (something like nightly-report-bot) so every run appends to the same tracker instead of spawning a new one per run.
3. Use user_id to link conversations. If the job serves a human, pass their user_id so you can retrieve all of their conversations and analyze patterns across runs.
4. Read the tracker before you act. The tracker store is queryable. Your job can pull the previous session's events and slots and inject a summary into the new session, bridging the session boundary Rasa drew for you.
5. Decide what a "new run" means. If each run should truly continue the last, carry slots over and suppress the session reset. If each run is a fresh task that only needs the facts, retrieve them explicitly instead of relying on ambient state.

When the memory spans more than Rasa

Here is the limit of the tracker approach: it only covers what happened inside Rasa. The moment your automation also touches n8n, a Python script, and a human in ChatGPT, each tool keeps its own private history. Rasa knows the conversations. The workflow tool knows the pipeline runs. Nothing knows the whole story.

That is the gap a hosted memory layer fills. Vilix AI is cloud-hosted with zero infrastructure to manage: the same memory follows your automations across every tool over MCP, so a scheduled job, a chat assistant, and a workflow agent all read and write one shared context. It stores full conversation history, not just extracted facts, so the real exchange is always retrievable. The free plan is free forever, the Pro trial runs 7 days with no credit card, and you can export or delete everything at any time.

The checklist

Does Rasa remember between runs? It remembers every event in a conversation, durably, once you configure a real tracker store. It does not connect yesterday's run to today's run on its own: new sender_id values, session boundaries, and the in-memory default all produce the same symptom, an agent that starts blank. Fix the sender_id, persist the store, and read the tracker deliberately, and Rasa gives you continuity. And when continuity has to cross tool boundaries, that is what a shared memory layer is for.