Does Restate Remember Between Runs? The Journal Replays One Invocation. The Next Run Still Starts Fresh.

Short answer: Restate remembers a great deal inside one invocation, and one specific kind of state across invocations, and still a new run does not start by loading the last run's work. Restate journals every step of an execution so a crashed run can replay and resume. Virtual Objects keep keyed state that persists for that key. A fresh workflow or service invocation, started by a schedule or a caller, begins with the inputs it was given. It does not open yesterday's journal, decisions, or reasoning before it begins.

That boundary is easy to miss because Restate feels like memory. A process can sleep for days, survive a restart, and finish exactly where it stopped. Surviving inside one job is a different job from remembering the last job.

What Restate is built to remember

Restate is a durable execution runtime, built by the original creators of Apache Flink. Your code runs as services, and the Restate Server sits in front of them. There is no external database, broker, or cache to run for the core system: the server is a single binary that stores its log and state on disk. SDKs cover TypeScript, Python, Java and Kotlin, Go, Rust, and Ruby.

Three building blocks carry different kinds of persistence:

• Basic Services are durable functions. Each invocation gets a journal.
• Virtual Objects are keyed, stateful entities. One key, one writer at a time, with state you read and write explicitly.
• Workflows coordinate a multi-step process that runs once for a given workflow ID.

Confusing those three is where most memory mistakes start.

Kept inside one invocation: the journal

As an invocation runs, every durable step is recorded in a journal before its result is handed back to your code. A call wrapped in a durable step, a service call, a sleep, a timer, and a wait for an external signal all land in that log.

Recovery is replay. If the process crashes, is redeployed, or is killed, Restate restarts the function and replays the journal. Completed steps return their recorded results instead of running again. Real work resumes at the first step with no recorded result.

For an AI step, that guarantee is valuable. A completed model or tool call does not get charged or executed twice just because the host died afterwards.

The journal is also scoped. It belongs to that invocation, not a briefing pack handed to the next invocation.

Kept across invocations: Virtual Object state, and only what you put there

Virtual Objects are the honest exception, and they deserve a precise description. A Virtual Object is identified by a key, for example a customer ID or a cart ID. Handlers for the same key run one at a time, so concurrent calls cannot race each other. Inside a handler you can read a value, update it, and store it back. That stored state persists beyond a single execution and can be shared between functions with strong consistency.

So a counter, a cart, or a small status record keyed to one entity can survive from one call to the next, because you designed it that way and wrote the values yourself.

Notice what that state is not. It is not the previous run's conversation. It is not the agent's reasoning, the alternatives it rejected, the customer context it gathered from three tools, or the summary a human would write after the job. It is keyed application data, in the shape you chose, for the entity you keyed it to. A scheduled agent that needs to know what happened across many customers, many workflows, and many tools gets no briefing from a Virtual Object unless you build that briefing, store it, load it, and keep it current by hand.

Workflows make the same point from the other side. A workflow runs once per ID, which protects you from duplicate runs of the same job. A second job, with a new ID, is a new workflow. It does not inherit the first workflow's journal.

What a scheduled AI agent actually needs on the next run

Consider a nightly agent that reviews new signups, enriches each record, drafts follow-ups, and flags accounts that need a human. On Monday it learns that one account is mid-migration, that another contact asked not to be emailed until next quarter, and that a third record is a test account that should always be skipped.

On Tuesday, a new Restate invocation can replay Monday's steps if Monday's invocation crashed. That is durability. What Tuesday's fresh run needs is different: Monday's conclusions, loaded before Tuesday starts, in a form the model can use. The journal does not do that loading. Virtual Object state does it only for the narrow keys and values you planned in advance.

Without a separate memory layer, the usual workaround is a hand-built summary table, a prompt stuffed with last week's output, and a growing list of exceptions nobody trusts. The agent repeats questions, redoes enrichment, and occasionally acts on a fact that changed after the summary was written.

The layer that carries the past into the next run

Vilix AI is that separate memory layer for scheduled agents. An agent in Restate, in another orchestrator, or in a plain cron script can read and write the same memory over MCP before, during, and after a run, so the next run starts with the shared past already available.

Vilix AI is cloud-hosted with zero infrastructure for you to run. There is no database, log store, or sync job to operate. The same memory is available everywhere over MCP, so a workflow in Restate, a script on a laptop, and an assistant in a chat tool can all draw on one shared record instead of separate copies that drift apart.

The memory holds full conversation history, not just extracted facts. When Tuesday's run needs to know why Monday's run skipped an account, it can revisit what was actually said and decided, not only a short field that says skipped. That distinction matters when a customer replies, a teammate asks for the reason, or a later run needs to change the decision with the original context intact.

Getting started does not require a commitment. Vilix AI has a free plan forever, and a 7-day Pro trial with no credit card. Your data stays portable: export everything or delete it anytime. You can test the pattern on one scheduled agent, check what the next run loads, and keep only what proves useful.

The practical test

Ask one question of any orchestration setup: if tonight's run learns something important, will tomorrow's run know it before it acts, without you copying it by hand?

Restate answers that question inside one invocation, and for keyed state you design yourself. For shared agent memory across runs and tools, add a memory layer built for that job, and let each system do the part it was designed for.

Give your scheduled agents one shared memory with Vilix AI and let the next run start informed.