Does Cloudflare Workflows Remember Between Runs? Inside an Instance, Yes. Across Instances, No.

Short answer: inside one instance, Cloudflare Workflows remembers a great deal. Across instances, it remembers nothing on its own. Each new instance starts with only the payload handed to it at creation. What the previous instance learned, decided, or produced is not carried into the next one unless that information was stored somewhere else and loaded back in on purpose.

That split is easy to miss. A single instance can sleep for days, wait for an approval, survive a failure, and resume exactly where it stopped. A scheduled setup built on top of the same Workflow can still act every morning as if yesterday never happened. Both behaviors are the design working as intended.

What a Workflow instance actually is

Cloudflare describes Workflows as a durable execution engine built on Workers for long-running, multi-step applications. A Workflow definition is code. An instance is one execution of that code, created with its own ID and its own event payload.

The distinction between definition and instance is where the memory question is decided. The definition persists because it is deployed code. The payload persists because it belongs to that instance. Learning from a run belongs to neither one automatically. It lives only inside the instance that produced it, for as long as that instance's stored state is retained.

What persists inside one instance

Inside an instance, persistence is real and automatic. Workflows uses a step-based model:

• Code wrapped in step.do runs as an individually retryable step. The value it returns is persisted, so a retry or a restart resumes from the completed steps instead of repeating them.
• step.sleep and step.sleepUntil pause an instance for a set duration or until a point in time, without holding a process open.
• step.waitForEvent pauses an instance until an external event arrives, such as a webhook or an approval.

Because step outputs are stored, an instance can run for minutes, hours, days, or weeks and still hold its thread. If infrastructure fails mid-run, the engine replays the recorded step results and continues from the last completed step. For reliability work, that is exactly the right guarantee: no completed step is lost, and no finished external call needs to be repeated just because a later step failed.

There are boundaries even here. Only values returned from steps are persisted in this way. Ordinary in-memory variables are not trusted to survive hibernation, which is why the guidance is to put anything that must endure inside a step. Stored instance state is also retained for a limited window by default, so a finished instance is a record to inspect for a while, not a permanent memory store.

What does not carry into the next instance

A new instance does not inherit step outputs, decisions, or context from a previous instance. It receives the event payload supplied when it is created, and nothing else is loaded for it automatically.

Recurring schedules make the edge visible. When a Workflow is configured with a schedule, each matching time creates a new instance automatically. The Tuesday instance and the Wednesday instance are siblings, not chapters. Wednesday does not read Tuesday's step results, does not know which items Tuesday processed, and does not know what Tuesday promised, skipped, or flagged, unless the code was written to fetch that information from an external store at the start of the run.

The same edge appears with agent-style work. Suppose a nightly instance reviews a queue, resolves half of it, and notes why the rest needs a human. If those notes exist only as step outputs inside that instance, the next nightly instance starts from the queue alone. It can re-review finished items, miss the human handoff context, and repeat a decision that was already made well. The workflow engine did its job. The missing piece is a memory layer whose scope is wider than one instance.

Durable execution is not agent memory

Durable execution answers the question: can this run finish reliably, even if something fails along the way? Agent memory answers a different question: can the next run start with what earlier runs learned?

Cloudflare Workflows is built for the first question. Its steps, retries, sleeps, and event waits keep one piece of work alive until it completes. Remembering across separate runs, across different tools, and across the conversations around the work is a separate concern, and it needs a separate home. External stores such as a database or object storage can hold hand-picked state for one workflow. That works when a team knows in advance exactly which fields the next run will need. It works less well when the useful context is the full history of what was discussed, decided, and tried, including the parts nobody thought to copy into a schema.

Giving scheduled agents one shared memory

That wider home is what Vilix AI is built to provide. Vilix AI is a cloud-hosted memory layer for AI tools and agents. There is no infrastructure to run or maintain: the memory is hosted, and connected tools reach it over MCP, the Model Context Protocol.

Three properties matter for scheduled automation in particular. First, the same memory is available everywhere the work happens, so a nightly Workflow instance, a second agent in another tool, and a person reviewing the result in a chat the next morning can all draw on one shared history instead of three partial ones. Second, Vilix AI stores full conversation history, not just extracted facts, so the reasoning behind a decision stays available alongside the decision itself. Third, the memory sits outside any single platform, so it survives a change of workflow engine, model, or tool.

Access stays simple and low risk to try. There is a free plan that stays free forever, and a 7-day Pro trial that needs no credit card. Data can be exported or deleted at any time, so adopting a shared memory never means surrendering control of it.

How to design with the edge in mind

Treat Cloudflare Workflows as the reliability layer, and be explicit about the memory layer:

1. Keep using steps for anything a single instance must not repeat after a failure.
2. Assume every new instance starts blank apart from its payload, and test that assumption with two runs in a row.
3. Decide where cross-run knowledge lives before the automation matters: which prior decisions, open items, and customer context the next instance must load before it acts.
4. Load that shared context at the start of the run and save the outcome back at the end, through a memory layer every tool in the setup can reach over MCP, such as Vilix AI.

Cloudflare Workflows remembers faithfully for the length of one instance. That is a strong foundation. Scheduled agents become dependable across days and weeks when the next instance is also given a memory of every instance before it.