Windmill Keeps the State You Save by Hand. Your Scheduled AI Steps Still Run Stateless.

Windmill is very good at making a job repeatable. A script becomes a flow, a flow gets a schedule, and the same work runs at the same time without anyone pressing a button. Repeatable, however, is not the same as remembering. A scheduled job can execute perfectly every morning and still have no idea what it concluded the morning before.

That sounds like a contradiction until you separate the three kinds of persistence Windmill actually offers, and notice what each one was built to hold.

The state a script saves for itself

The strongest cross-run tool in Windmill is script state. Using the client helpers for getting and setting state, a script can leave a value behind and read it back on its next execution. Teams use it for the last run time, a sync checkpoint, or a marker that tells the next run where the previous one stopped.

Useful, and deliberately small. State is a shelf with room for the values your code explicitly places there. Nothing lands on that shelf by accident. The argument an AI step made for ranking one item above another, the exception a reviewer approved, the dead end a run explored before finding the right answer: none of that is saved unless the script was designed, in advance, to turn it into a stored value. And once you start storing richer history that way, you are no longer just using state. You are building a private memory system, one script at a time, and maintaining it for as long as the job runs.

The state that only lives as long as the flow

Windmill flows also have their own user state, a key-and-value space that any step in a flow can read and write during an execution. It is a handy escape hatch when step outputs do not line up neatly, or when several steps need to consult the same working value.

Its lifetime gives it away: the flow job itself. A value set in step two is available in step five because both belong to the same job. When that job ends, the space ends. Tomorrow's job is a different job, with a fresh state, even though the flow definition, the schedule, and the team waiting on the result are all identical. Inside-run sharing and across-run memory look alike in a diagram. In a calendar, they are opposites.

Why the AI step forgets the schedule

The most surprising piece is the AI agent step, because in chat it can clearly remember. Windmill's managed memory for an agent step can replay recent messages, or keep the whole conversation and compress older parts as space runs short. In a chat flow, each new message arrives with a conversation identity, so the step knows which history to load.

A scheduled run arrives with no such identity. Windmill's own documentation is blunt about the consequence: schedules, webhooks, evaluations, and plain runs pass no memory id, so they run stateless. The agent is not failing to remember. It was never handed a memory to remember with. Memory is off by default, and a recurring trigger does not turn it on.

Operators can work around this by pinning a memory id onto the step, fixed for every run or built from an input such as a customer reference. That choice deserves care. A single fixed id merges every scheduled job into one continuous thread, whether those jobs were about the same subject or not. Per-key ids split memory into silos that have to be managed. Either way, what gets stored is that step's conversation, inside Windmill, for that flow. It is not a history the rest of your stack can consult.

Resources remember settings, not stories

The remaining persistent pieces, resources and variables, hold the stable facts of a workspace: connections, credentials, thresholds, and settings, all permissioned by path. Every run benefits from them, and they should persist.

But a setting is not a story. Knowing which database to query says nothing about what the last query found. Knowing a customer's plan says nothing about the promise made to that customer in last Thursday's run. When operators try to stretch configuration stores into memory stores, the result is usually a growing pile of values with no narrative attached, readable as data and useless as context.

The pattern underneath the gap

Notice the common thread. Every Windmill persistence tool is scoped: to a script, to a job, to a step's conversation, or to a workspace setting. Scoped memory is tidy, and for many jobs it is enough. The gap appears when the work itself is unscoped, when Monday's research should inform Tuesday's brief, when the same subject is touched by a Windmill flow, a second automation tool, and a person chatting with an assistant, and all three need the same past.

At that point, adding more scoped stores makes the fragmentation worse. Each tool remembers its fragment faithfully, and the operator becomes the integration layer, copying context from one fragment to another by hand.

One memory, outside any single job

The fix is architectural, not heroic: move the memory out of the job entirely. A run starts by reading from a shared memory that existed before it and will exist after it. It does its work with that history in view. It finishes by saving what changed, in full, for whichever tool runs next.

Vilix AI is built to be that shared memory. It is hosted in the cloud, with zero infrastructure for you to run, and it connects over MCP, so the same memory follows your work across automation platforms, coding tools, and chat interfaces instead of living inside any one of them. It preserves full conversation history, not just facts distilled from conversations, so the next run gets the actual reasoning and wording behind earlier decisions, not a checkpoint value standing in for them.

There is nothing to lose by trying it: the free plan is free forever, the 7-day Pro trial requires no credit card, and your stored data can be exported or deleted at any time. Let Windmill do what it does best, turning scripts into reliable scheduled work. Let one shared memory do the remembering between those runs.