Your Activepieces Copilot Remembers You. Your Scheduled Flows Still Start Blank.

Quick answer: Activepieces' AI chat assistant remembers your preferences across conversations. Your scheduled flow runs do not. A flow wakes up with the trigger input and the static shape of the flow, and nothing else. The only way to carry state between runs is to deliberately write it down, with the Store piece or Tables, and read it back next time.

Two memories live inside Activepieces, and they never meet. Once you see the split, every "why did it forget that?" moment makes sense.

The memory that works: the Copilot chat

If you use the AI chat assistant inside Activepieces, it remembers you. The team shipped cross-session memory for the assistant, so you stop re-explaining your preferences and context every time you open it.

What it keeps is personal to you, the operator:

• Personal instructions — an always-on field for how you want the assistant to work and sound. It gets injected into every chat turn.
• Memory — a curated list of durable facts the assistant picks up and silently reconciles itself, so a changed preference replaces the old fact instead of stacking next to it.

Caps: 50 facts of about 280 characters each, 4,000 characters of instructions. Enterprise/Cloud only, not in the self-hosted Community edition.

That is a real memory system. The catch is where it lives: the assistant that helps you build flows. It knows your tone preferences. It does not know that yesterday's 2 a.m. run flagged three hot leads. Different room entirely.

The memory your flow runs don't have

A scheduled Activepieces flow is stateless. Every run starts fresh: it gets the trigger input and the static shape of the flow you designed. When the run ends, the run's working state ends with it.

Run history is a debugging log built for your eyes. There is no step you can drop into a flow that reads last Tuesday's run and feeds it into this Tuesday's AI prompt.

So the next run wakes up with exactly two things: the fresh trigger input and the flow definition. No trace of the previous run's outputs. No record of what the AI step decided.

The Store piece: the bridge you have to build yourself

Activepieces gives you a deliberate way to carry state across runs: the built-in Store piece. It is a persistent key-value store. Values you put there are retained after the piece executes, so a later run can get them back.

The design tells you how the team thinks about it:

• Put, Get, Delete. You store a value under a key, read it back later, or remove it.
• Flow scope by default, project scope if you ask. State in one flow's scope is invisible to other flows.
• Small values. Keys top out at 128 characters, values at 512 KB. For megabytes, the docs point you at the Tables piece, the built-in project database.

This is honest infrastructure. The part most people miss: you have to wire it. The Store piece does not watch your AI step and quietly save what it decided. You add a Store Get at the top of the flow, feed the retrieved state into your AI prompt, and add a Store Put at the bottom to save the new state. Forget the Put, and the next run wakes up blank. Every AI step that needs continuity needs the same plumbing, repeated by hand.

Project Variables solve a different problem. They are static named values, an API key, a channel ID, a feature flag, referenced from any step in any flow. They stay the same until you change them. Configuration, not memory.

What this costs you, in concrete terms

Picture the nightly lead-scoring flow. An AI step scores the day's new leads. A hot lead that arrived yesterday should skip re-scoring and move straight to follow-up. Without state, the flow re-scores everything from scratch, burns tokens, and risks re-contacting the same person. The fix is Store: save yesterday's scored list under a date key, read it at the start, score only the arrivals, overwrite the key at the end.

Or the daily digest flow. An AI step summarizes the day's support tickets for Slack. If the digest should reference what it promised yesterday, the flow has to remember its own output. The chat assistant's memory of your tone preferences does not help here. Only Store or Tables can carry that forward, and only because you put it there.

Both examples share the same failure mode: silent. Nothing errors. The flow just behaves like it is Monday every morning.

The two-room problem

Activepieces has an operator memory (the chat assistant knows you) and a run memory (the Store piece holds what you explicitly save). They do not share anything. The assistant that remembers your preferences cannot see the state your flows carry, and the flows cannot see what the assistant learned about you.

The run side is where context compounds. Last month's qualified leads, last week's pricing decision, the customer who said "call back in Q4". Today that lives in keys you set by hand, or nowhere.

Give your flows one memory instead of per-flow plumbing

The Store pattern works, but it scales the way manual plumbing scales: every flow, every AI step, every key, maintained by hand. Keys drift. Two flows end up tracking the same customer under two different keys. The model that reconciles contradictions in the chat assistant's memory has no counterpart on the flow side; a stale fact just sits there until you notice.

The cleaner answer is one shared memory layer that every flow reads from and writes to, instead of each flow maintaining its own private keys. That is what Vilix AI is: a cloud-hosted memory layer your automations talk to over MCP, with zero infrastructure for you to run. Every scheduled agent, whether it lives in Activepieces, n8n, Make, or Zapier, reads the same memory and writes back to it, so context compounds instead of resetting. And because it keeps full conversation history, not just key-value facts, your flows can look back at what actually happened last run, not just the summary you remembered to store.

The plan is free forever, with a 7-day Pro trial that needs no credit card, and everything you put in can be exported or deleted anytime. Nothing to install, nothing to maintain.

The takeaway

Ask which memory you are asking about. The Activepieces chat assistant remembers you, the operator: your instructions, your preferences, your facts, reconciled across conversations. Your scheduled flows remember nothing between runs unless you explicitly save state with the Store piece or Tables and read it back. Two rooms, one wall between them. Until flows share one memory, the Store Get at the top and the Store Put at the bottom are the difference between an automation that learns and one that wakes up with amnesia on a schedule.