Your Sim Studio Agent Has a Memory Switch. Most Scheduled Runs Leave It Off.

You built the nightly pipeline in Sim Studio. A scheduled workflow fires at 2 AM, an Agent block reads the day's support tickets, classifies them, drafts replies, and logs the results. Night one, it works. Night two, it works. By night thirty, you notice something odd. The agent re-classified the same tricky ticket it already resolved last week. It re-asked a question a customer already answered. Nothing broke. No error in the logs. The workflow ran green every single night. The agent just never learned a thing.

That is the memory switch. Sim Studio's Agent block ships with built-in conversation memory, and it is genuinely good. But it stays off in the way that matters, and even when it is on, it remembers in a very specific shape. If your scheduled runs generate a fresh conversation every time, your agent wakes up blind every night, and no amount of careful prompting fixes that.

The short answer to the question everyone asks: yes, Sim Studio remembers between runs, but only when the Agent block gets a conversation ID and a memory mode is selected. Everything else is detail, and the details are where scheduled runs go wrong.

The four memory modes

Open an Agent block and you will find the memory setting with four options, documented in Sim's official docs:

• None. Each run is independent. The agent sees only the current input.
• Conversation. Stored history for that conversation ID, subject to history-loading and model context limits.
• Sliding window (messages). The most recent N messages are recalled.
• Sliding window (tokens). Recent history selected against a token budget, keeping tool exchanges together.

The docs carry one sentence that decides everything: "Memory needs a conversation ID to persist between runs." No conversation ID, no memory. A new conversation ID on every run gives the same result: every run is run number one.

This is the failure mode that catches operators running scheduled workflows. The trigger fires, the workflow builds a fresh execution, the Agent block starts with an empty or auto-generated conversation ID, and the memory feature you thought you enabled quietly does nothing. The fix is mechanical, not clever: give scheduled runs a stable conversation ID. Key it to whatever the run processes, a per-customer key for a support agent, a per-pipeline key for a nightly job, so Tuesday's run and Wednesday's run count as the same conversation.

What the memory covers, and where it stops

Three things operators tend to learn the hard way:

1. Memory is per conversation, not per workspace. The built-in agent_memory_read tool lets the agent search its retained history and read truncated result details in small pages, but it can only read the current conversation. When memory has to be shared across workflows, or managed as its own store, the docs point to the separate Memory block instead. Two workflows serving the same customer will not see each other's history unless you design for it.

2. Recalled is not the same as stored. The sliding windows change what the model receives, not what is stored. Sim targets up to about 16,000 estimated tokens of recalled history per generation, and when older history would be dropped, it can generate a concise summary while keeping recent exchanges. Summaries omit details and do not replace the stored conversation. In practice the agent remembers the shape of last month, not the specifics. When exact details matter, the docs advise having the agent check the original result rather than trusting its preview.

3. Tool history is durable, but only going forward. With durable tool history enabled for the workspace, memory keeps the assistant messages that led to tool calls, the calls' original arguments, and their results or errors. Later runs can reuse completed tool exchanges even when the run that produced them failed before answering, which is a real resilience feature. But it is captured on new runs after the feature is switched on, and a new workflow execution is still a separate invocation. Retries inside a run continue where they stopped. A fresh scheduled run starts from stored history, not from the live state of the crashed one.

The operator's checklist

The setup that actually accumulates knowledge across scheduled runs looks like this: choose a memory mode other than None, assign a stable conversation ID that survives across executions, reach for the Memory block when state must be shared across workflows, and enable durable tool history so failed runs leave something behind. Then watch one thing: whether the agent's decisions actually change week over week. Memory that never changes behavior is decoration.

There is one more boundary worth naming. Sim's memory is excellent inside Sim. But most operators do not live inside a single platform. The same team runs the nightly job in Sim Studio, the webhook handler in n8n, a support macro as a ChatGPT scheduled task, and a lead-scoring script in plain code. Each of those has its own memory story, its own conversation IDs, its own windows. The agent that enriches leads in Sim never sees what the follow-up agent learned in n8n. That is the same blind-wakeup problem, one layer up.

That is the gap Vilix AI is built for. It is a cloud-hosted memory layer with zero infrastructure to manage, and every AI tool reads the same memory over MCP: Sim Studio, n8n, Claude, ChatGPT, your own code. It stores full conversation history, not just extracted facts, so the reasoning behind a decision survives alongside the outcome. There is a free plan forever, a 7-day Pro trial with no credit card, and you can export or delete everything anytime. One memory, every agent, every run. The 2 AM run stops being run number one.

Get started for free