Does Notion Automations Remember Between Runs?

No. A Notion database automation carries no memory from one run to the next. Every run starts when its trigger fires, reads the page and properties as they stand at that moment, carries out its actions, and ends. The next run starts from a new trigger, with no record of what the previous run calculated, decided, or passed between its own steps.

The workspace can feel continuous. The same automation assigns every new task, stamps every completed date, and posts to the same Slack channel every morning. That continuity lives in the database and in the automation definition. It does not live in the automation itself.

What does one run actually hold?

Inside a single run, an automation has real working context. The trigger supplies the starting facts: which page was added, which property was edited and what it changed to, or the fact that a scheduled time has arrived. Conditions narrow the run further, so actions only apply to pages that match.

An automation can also define variables. The Define variables action builds a custom value from mentions and formulas, such as the trigger page, the current time, or a value pulled from a property, and later actions in the same run can reuse that variable in a notification, an email, or a property edit.

That context is scoped to the run. When the last action finishes, the variables are gone. No later run can ask what an earlier run defined, because there is no variable store that survives between runs. A variable is a value computed fresh each time, never a note left behind by the last execution.

What persists between runs, and where?

Only what an action deliberately writes to a database persists, and it persists as data, not as memory.

Properties are the main store. An action can edit a property on the trigger page, add a page to another database, or edit pages in another database. A run can stamp a Last processed date, set a Status, increment nothing on its own but write a formula result into a field, and the next run can read those values back as ordinary properties. If a value was never written to a property, it does not exist for the next run.

Page content is the second store. An automation can create pages with set content, and people and other tools can read that content later. It works as a visible record. It is also unstructured for the automation itself: the next run triggers on properties, not on reasoning written into a page body, so anything stored only as prose has to be found and interpreted by someone or something else.

The automation definition is the third thing that persists. Triggers, conditions, and actions stay exactly as configured until someone edits them. That is consistency, not memory. The rule remembers how to behave. It does not remember what it did.

The limits that shape every run

Three documented limits follow directly from that design. Database automations cannot be triggered by other automations, so runs cannot hand context to each other through a chain; only a person clicking a button that creates a page can start that kind of sequence. A recurring Every trigger, the daily or weekly schedule, cannot be paired with another trigger type, and it works with every action except Edit property, so a scheduled run cannot even stamp its own trigger page directly. And an automation only sees the database world in front of it: the trigger page, its properties, and the databases its actions are allowed to edit.

None of this is a flaw in a rule engine. It is what a rule engine is. The problem starts when a run needs judgment that builds over time.

The gap an AI step falls into

Add an AI step to the flow and the gap becomes concrete. Picture a requests database: an automation fires when a page is added, sends the page properties out through a webhook to an AI agent, and the agent classifies the request, drafts a response, and writes a summary and a priority back into properties.

On the next run, the database shows what was written. It shows a priority label and a summary field. It does not show why the agent set that priority, which earlier requests shaped the draft, what the agent concluded about a similar borderline request last month, or what a second agent working in another tool decided about the same customer. The properties hold outcomes. The reasoning, the comparisons, and the thread of prior work are conversation context, and no property, variable, or page body in Notion was built to hold and retrieve that for the next run.

So the AI step wakes up blank in the way that matters. It can be re-briefed from property values on every run, at the cost of a briefing that only ever contains what someone remembered to flatten into a field.

What changes when memory lives outside the database

Vilix AI is a cloud-hosted memory layer that sits outside any single database or workspace tool, so there is no infrastructure to run alongside your automations. A scheduled agent connects to Vilix AI over MCP. At the start of a run it retrieves the relevant saved context, and at the end it saves what it did and decided.

That memory holds full conversation history, not just facts or final values, so a later run can revisit what was actually said, tried, and concluded, not only the label that survived in a property. The same memory follows the work everywhere: the same saved context is available to an agent reached from a Notion webhook, to an agent in another automation platform, and to the AI tools used during the day, because every one of them connects to the same layer over MCP.

For the requests automation, the difference is concrete. Run two no longer starts from a priority field. It retrieves the prior classifications, the borderline calls and the reasons behind them, and the earlier thread for each requester, then saves the new decisions back for run three. Notion keeps doing what it does well, which is holding the work, firing the triggers, and keeping the record visible. The memory of the work stops depending on properties and page bodies.

Getting started is light. Vilix AI offers a free plan forever, a 7-day Pro trial with no credit card, and the ability to export everything or delete it anytime, so the memory an automation builds stays portable and under the operator's control.

The short answer

Notion Automations do not remember between runs. A run starts from its trigger, variables live only inside that run, and only what an action writes to a property or a page survives, as flat data with none of the reasoning attached. Scheduled automations that include AI steps need a memory layer built for that past work. Give the agent one shared memory outside the database, and each run starts from what the last run learned instead of from a blank context and a status field.