Does Google Cloud Workflows Remember Between Runs? Variables Live Inside One Execution, Not the Next.

Short answer: Google Cloud Workflows keeps state carefully inside one execution, and it does not carry that state into the next execution. Variables assigned in one run, the results of its steps, and the decisions made along the way belong to that execution alone. A new execution starts from its input argument and the workflow definition, nothing more, unless the workflow was built to load earlier information from somewhere else first.

That boundary is easy to miss because a single execution can feel very stateful. It can wait, poll, and hold its variables for a long time. Holding one job together is not the same job as remembering yesterday's job.

One workflow, many separate executions

A workflow is the definition written in YAML or JSON: steps, calls, conditions, retries, and assignments in order. An execution is one run of that definition. A scheduler, an event, or an API call can each create a new execution, and every new execution gets its own identity, its own variables, and its own result.

The definition persists because it is deployed configuration. The execution record persists because Google Cloud keeps it available for inspection. What an execution learned while working persists in neither place as a starting point for the next execution. The next execution does not open the previous execution's variables before it begins. It starts, reads its own argument, and works from there.

A workflow can stay unchanged for months and still act as if each day is the first day, because nothing hands it the last day's context automatically.

What persists inside one execution

Inside one execution, Workflows is built to hold state together across steps.

Variables are the centre of it. A step can assign values, later steps can read and update them, and the service keeps that execution state while the execution is active. Google Cloud documents a cap of 512 KB for all variables in one execution, which is enough for the counters, lists, flags, and intermediate results a single orchestrated job normally needs.

Time strengthens the point. An execution can wait for a callback, poll an external service, or pause between steps, and it can stay alive for up to a year. During that whole period the current step and its variables are kept by the service. A long approval flow, a slow vendor response, or a job that checks back every hour can therefore carry its context forward inside itself without any external store.

Step results work the same way. A call step stores its result in a variable, a switch step branches on it, and later steps use it to decide what happens next. Retry and error handling depend on that shared context.

All of that persistence ends at the execution boundary. It connects steps inside a run. It does not connect runs to each other.

What the next execution does not get

A new execution does not inherit the previous execution's variables. It does not automatically receive the items the last run already processed, the customers it already contacted, the branch it chose, or the reason it skipped something.

A scheduled example shows the gap plainly. Suppose a workflow runs every morning, checks open orders, sends follow-ups for the ones that need attention, and works out that three orders need nothing because payment already arrived through another channel. If that finding lives only in variables inside today's execution, tomorrow's execution sees the open orders again and none of the reasoning. It can send the same follow-ups again and treat a settled question as a new one. Workflows executed correctly both mornings. The second morning simply began without the first morning's memory.

The common workaround proves the same point. Guidance for state across executions points to an external store, typically Firestore, used as a hand-built key and value layer: one step writes state, a later execution reads it back. That works for the values someone chose to save, for that one workflow. There is no intrinsic cross-execution store in Workflows itself, so discussion in other tools and decisions made outside the workflow stay outside the next execution's reach.

Execution history is a record, not a memory

Execution history still matters. Step entries show which steps ran, how long they took, and whether they succeeded, and detailed history can include variable values at each step. That makes debugging and auditing far easier.

Memory for a scheduled agent has a different job. It has to be present before the agent acts, not only available for a person to inspect after it acted. It has to carry decisions, open items, and the full context around the work, not only the variables one workflow happened to hold. And it has to be reachable from every tool taking part in the work, not only from the executions list of one Google Cloud project.

A hand-built Firestore layer covers part of that job for one workflow. It does not cover a workflow in another platform, an assistant in chat, or a second agent handling the next stage. Each still starts with its own slice, unless they share a memory outside all of them.

Giving scheduled workflows one shared memory

That shared memory is what Vilix AI provides. Vilix AI is a cloud-hosted memory layer for AI tools and agents, with no infrastructure to run or maintain. Connected tools and agents reach the same memory over MCP, the Model Context Protocol, so a scheduled Workflows execution, another agent in a different platform, and a person reviewing the work can all begin from one shared history instead of separate execution records.

Vilix AI stores full conversation history, not just extracted facts. For recurring work, that means the decision itself and the discussion behind it are both available for the next run to load, not only a status value copied into a document store. Because the memory lives outside any single platform, it also remains available if a workflow moves to another orchestrator, the model behind a step changes, or a new tool joins the setup.

Trying it carries little risk. 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 control stays with the owner of the memory.

How to design around the boundary

1. Use variables for what they are designed for: carrying state between steps inside one execution.
2. Assume every new execution starts blank apart from its argument, and confirm it by running the workflow twice and comparing what the second run knows.
3. Write down what tomorrow's execution must know before it acts: settled decisions, items already handled, prior contacts, and open questions.
4. Give that knowledge a home the next execution actually loads at the start and updates at the end, through a shared memory layer reachable over MCP, such as Vilix AI.

Google Cloud Workflows remembers an execution in detail while it runs and keeps a clear record after it finishes. Scheduled agents become dependable across days when the next execution is also given what every execution before it learned.