# EP 16: Do Windmill Scheduled AI Steps Remember Between Runs? - URL: https://www.agenticpod.net/episodes/ep16-windmill-scheduled-ai-steps-memory/ - Watch on YouTube: https://www.youtube.com/watch?v=2xzrhK6UHKw - Published: 2026-10-16 - Length: 5 min - Hosts: Stella (asks), Liam (answers). Both are AI hosts with AI-generated voices. ## Summary Windmill's own docs say schedules, webhooks and plain runs pass no memory id, so an AI step in a scheduled flow runs stateless. ## Key takeaways - Windmill's docs say schedules, webhooks, evaluations and plain runs pass no memory id, so a scheduled AI step runs stateless. - Script state is a small shelf: only the values your code saves are there. - Flow state lives as long as the flow job, then it is gone. - A single pinned memory id merges every scheduled job into one thread, and per-key ids create silos. - With Vilix AI each run starts with get_context and ends with save_turn, so the next run keeps the full history, newest memory wins. ## Chapters - 0:00 Intro - 0:40 Why the scheduled AI step forgets - 1:37 Script state and flow state - 2:26 How Vilix AI fixes it - 3:36 Rules, agencies and recap ## FAQ **Do Windmill scheduled AI steps remember between runs?** By Windmill's documentation, schedules, webhooks, evaluations and plain runs pass no memory id, so they run stateless, and agent memory is off by default. **Does Windmill flow state carry over to tomorrow?** No. Flow user state lives as long as the flow job, and tomorrow's job starts with a fresh state. **How does Vilix AI give a scheduled step memory?** The step calls get_context at the start and save_turn at the end over MCP, so the memory lives outside any single job and is shared with your other tools. **How do agencies handle this for clients?** Use one Vilix AI account per client, so every flow built for that client keeps a separate memory. ## Resources - [Full technical guide (setup, copy-paste prompts, FAQ)](https://github.com/asly-97/ai-automation-workflows/tree/main/windmill-scheduled-ai-steps-memory) - [The blog post behind this episode](https://vilix.ai/blog/windmill-keeps-the-state-you-save-by-hand-your-scheduled-ai-steps-still-run-stateless/) - [Vilix AI, one shared memory for ChatGPT, Claude, Claude Code, Codex, Cursor, OpenClaw, Hermes, n8n and every MCP tool](https://vilix.ai) - [Connect Vilix AI in under two minutes per tool](https://vilix.ai/get-started) ## Transcript ### Intro Liam: Hey hey hey, welcome to Agentic Pod! I'm Liam. Stella: And I'm Stella! Liam, Windmill's own docs say scheduled runs pass no memory id. So an AI step in a scheduled flow runs stateless. Liam: Yep. I mean, Windmill is great at repeating a job. But repeating isn't remembering. Stella: Okay, ouch. That's my Monday. Every Monday, I'm stateless. Liam: Same. Today: why your scheduled AI step forgets, and how Vilix AI gives it a memory that outlives the job. ### Why the scheduled AI step forgets Stella: So in chat, the Windmill agent step remembers. What changes on a schedule? Liam: In a chat flow, each message arrives with a conversation identity. So the step knows which history to load. A schedule has no such identity. Stella: And memory is off by default, right? Liam: Right. The docs say schedules, webhooks, evaluations and plain runs pass no memory id, so they run stateless. The agent isn't failing to remember. It was never handed a memory. Stella: Wait, can't I just, like, pin an id on the step? Liam: You can. Fixed for every run, or built from an input like a customer reference. But one fixed id merges every scheduled job into one thread. Stella: And ids per customer? Liam: Then you manage a pile of silos. And each one lives inside that one flow. Stella: Hmm. What about the state stuff I keep hearing about? Liam: That's next. ### Script state and flow state Liam: Windmill has script state. A script sets a value, then reads it on its next run. People use it for a last run time or a sync checkpoint. Stella: That sounds like memory to me. Liam: It's, you know, a shelf. Only what your code puts on it is there. The reasoning behind a ranking, the exception someone approved, the dead end a run explored, none of that is saved unless you built it in. Stella: And flow state? Liam: It lives as long as the flow job. Step two writes, step five reads, the job ends, and it's gone. Tomorrow is a new job. Stella: So inside the run it shares. Across runs, nothing. Liam: Exactly. And once you store richer history by hand, you're building a private memory system, one script at a time. Stella: Okay, I don't want a hobby. What's the fix? ### How Vilix AI fixes it Liam: Move the memory outside the job. Vilix AI is a shared memory your runs connect to over MCP, the plug that lets an AI app use outside tools. Stella: And what does a run actually do? Liam: At the start, the step calls get_context, so it reads what earlier runs and other tools saved. At the end, it calls save_turn, with the full conversation, not a summary. Stella: Full history. So the next run sees the real reasoning. Liam: Right. And every save carries a source label, so you know if it came from Windmill, Claude Code or Cursor. Failures get saved too, so a run doesn't retry the same dead end. Stella: What if two tools disagree? Liam: Newest memory wins. Correct it once in Vilix AI, and every tool sees the new truth. Stella: And the one-thread problem? Or silos? Liam: With Vilix AI you use projects. Each project holds its own memory, so jobs for different subjects stay apart, and your tools still share what's relevant. Stella: So the memory isn't tied to one flow anymore. Liam: Exactly. It lives in Vilix AI, outside any single job. ### Rules, agencies and recap Stella: Um, what about instructions I repeat every run, like tone or format? Liam: Those go in user rules and project rules in Vilix AI. Every connected tool loads them. And reusable procedures live as skills. Stella: And if I'm one human with ten agents? Liam: Uh, the agent inbox. You post one message, and your agents get it on their next read. Urgent ones repeat until the agent acknowledges. Stella: Okay. And agencies? Because I know people running this for clients. Liam: One Vilix AI account per client, like a Gmail account that belongs to that client. Every flow you build for them connects to their account, so the memory belongs to their business. Stella: So Windmill keeps doing what it's great at. Liam: Windmill makes the work repeatable. Vilix AI makes it remember. Quick recap. Scheduled runs pass no memory id. Script state is a shelf, and flow state ends with the job. With Vilix AI, get_context first, save_turn last, newest memory wins. The guide and the blog post are in the description, and setup takes under two minutes per tool at vilix.ai. Which scheduled flow would you give a memory first? Tell us in the comments. See you next time!