Mastra Remembers Every Thread. Your Scheduled Runs Still Start a New One.

Your Mastra agent runs every morning at 7, triaging the overnight support inbox. Inside the dashboard, the conversation history looks perfect: every turn saved, every tool call logged, the agent even keeps a running profile of repeat customers. So when Monday's run confidently re-opens a ticket that was resolved on Friday, and asks a customer for details they gave three days ago, it feels like a bug. It is not a bug. It is the thread model doing exactly what it was told to do.

This is the honest answer to "does Mastra remember between runs": it remembers everything you put in a place it can find again. The catch is that where it looks is narrower than most people assume, and scheduled automations almost always point it at the wrong place.

The three layers, and what each one actually covers

Mastra gives an agent three kinds of memory, and they behave very differently.

Message history (lastMessages) is a sliding window of recent turns inside one thread. Think of a thread as a single conversation. The agent sees the last N messages so the current turn stays coherent. When the thread ends, that window is just history in storage, not something the next thread automatically reads.

Semantic recall is long-term retrieval. Past messages get embedded into a vector store, and each new turn queries it for similar content. This is how the agent "recalls" something said two weeks ago without the full transcript in context. It needs a vector store configured (Chroma, Qdrant, Pinecone, or similar); without one, this layer quietly does nothing.

Working memory is the interesting one. It is a persistent scratchpad, a Markdown profile the LLM itself updates between turns: user preferences, goals, running task state. It comes in two scopes. Thread-scoped working memory belongs to one conversation. Resource-scoped working memory belongs to a resource (usually the user) and persists across all of that resource's threads.

That scope choice is the single most consequential line in a Mastra memory config. The two scopes are mutually exclusive: if you switch from thread scope to resource scope, the agent loses visibility into everything stored under the other one. It does not merge. Pick the scope when you design the agent, and do not change it later unless you accept a clean slate.

The thread ID problem in scheduled automations

Here is where cron jobs fall over. Every Mastra conversation lives in a thread, and a thread is just an ID. When a request comes in, you pass memory.thread (the conversation ID) and memory.resource (the user or system ID). If your 7am job fires agent.generate() without passing a thread ID, Mastra creates a fresh thread. A fresh thread has an empty message window. Semantic recall can still surface similar past messages, and resource-scoped working memory still loads, but the conversation itself starts over. Friday's ticket resolution lives in Friday's thread, and Monday's run never opens it.

The fix is to manage thread IDs like the durable keys they are. Store the thread ID in your own database when the run starts, and pass the same one next time if you want continuity. Give long-running workflows one thread per workflow instance, not one per run. And always pass memory.resource: without it, working memory silently drops back to thread-only, which means nothing crosses conversations at all. That one missing parameter is the most common reason people conclude "Mastra memory doesn't work" when it is actually working exactly as configured.

Storage is the other silent killer. Mastra's stores are pluggable: libSQL, PostgreSQL, Upstash, MongoDB for messages, plus a separate vector store for recall. The default local setup is fine for development, but if your scheduled job runs in a container or serverless function with ephemeral disk, the local store dies with the process and your "persistent" memory was never persistent. Point memory at a real database before you schedule anything. This is the kind of thing that works flawlessly for a month of manual testing and breaks the week you automate it.

So what survives between runs?

A fair summary: resource-scoped working memory and semantic recall survive between runs; thread contents do not transfer to new threads. Your agent keeps the customer profile and can retrieve similar past conversations, but it does not wake up inside last night's conversation unless you hand it last night's thread ID. That is a reasonable design for a framework. It is just not the same thing as "the agent remembers everything," and automations designed around the stronger assumption are the ones that re-open Friday's ticket on Monday.

The boundary Mastra memory does not cross

There is one more limit worth naming, because it bites automation operators specifically. Mastra's memory lives inside your Mastra instance and the code that calls it. If your 7am triage runs in Mastra, your midday follow-ups run in an n8n workflow, and your team asks questions through a separate dashboard bot, none of them share context. Each tool keeps its own history. The triage agent learns that a customer prefers short replies; the n8n workflow never hears about it; the dashboard bot asks the same customer the same question twice.

This is the actual problem behind most "my agents forget everything" complaints. It is not that the framework lacks memory. It is that memory is local to the thing that wrote it, and an automation stack is never one thing.

That is the gap Vilix AI is built for: one memory layer that follows your agents across tools instead of living inside one of them. It is cloud-hosted, so there is no database to provision or vector store to wire up. The same memory is available everywhere over MCP, so the Mastra triage agent, the n8n workflow, and the dashboard bot all read and write the same context. It stores full conversation history, not just extracted facts, so last Friday's ticket thread is there verbatim when Monday's run needs it. There is a free plan that stays free, a 7-day Pro trial with no credit card, and you can export or delete everything at any time. One memory, every tool, every run. Learn more at Vilix AI.

The takeaway

Mastra's memory is real and well designed: a message window for the current thread, semantic recall for the long tail, and a working-memory scratchpad scoped to the thread or the resource. Between scheduled runs, the resource-scoped layers carry forward and thread contents stay where they are. Design your thread IDs deliberately, always pass the resource ID, put storage on a real database, and your agent will genuinely remember. And when the thing you need remembered lives outside Mastra entirely, that is the point where a shared memory layer stops being optional.

Next in this series: what happens when two different automation platforms each insist they remember, and neither one has heard of the other.