Kestra AI Agents Remember With the Right Memory ID. Your Scheduled Flows Still Need a Shared Past.

A scheduled Kestra flow can look like it remembers. It runs at the same time every day, reads the same systems, and produces the same kind of report. Open two executions side by side, though, and a quieter truth shows up: each execution knows the flow definition and its own inputs, and almost nothing else. Whatever yesterday's execution learned has to be deliberately stored and deliberately reloaded, or it plays no part in today's work.

Kestra does offer real memory for its AI Agent tasks. Sorting out where that memory starts and stops decides whether a recurring automation improves over time or simply repeats itself.

Start with the plain flow, because most of the stack is one

Before any AI is involved, a Kestra flow is tasks in sequence, in parallel, or in loops, started by a schedule, a webhook, or another event. Data moves inside an execution through task outputs and expressions. One task fetches rows, the next transforms them, a third sends a message built from the results.

None of that movement crosses the execution boundary by itself. The outputs belong to the execution that produced them. A new execution re-runs the same definition against new inputs. If a task needs to know the high-water mark from last time, the flow author has to arrange for that value to be saved somewhere durable and fetched again. The orchestrator guarantees the run happens. It does not guarantee the run knows anything.

The namespace KV store is the hand-built bridge

Kestra's key-value store, organized by namespace, is that durable somewhere for simple values. Dedicated KV tasks set a key during one execution and get it during a later one. Flows use it to track state between executions: the last file processed, the previous version of a watched document, a flag that says a step already ran.

Used well, that bridge handles checkpoints cleanly. It is also, by design, a store for values, not a memory of work. A key can hold the last processed ID. It cannot, without a lot of surrounding code, hold the full story of how a tricky case was judged last month, what a human reviewer changed in a draft, or which of three conflicting sources turned out to be right. Every team that builds that story-keeping on top of KV keys invents its own format, and the result is readable mainly by the flow that wrote it.

Variables and inputs persist too, but they hold configuration set in advance: thresholds, endpoints, choices about how the flow should behave. Configuration tells a run how to act. It says nothing about what any earlier run actually did.

The AI Agent exception, and how it is switched on

AI Agent tasks, introduced with Kestra 1.0, change the picture inside their own boundary. An agent task combines a system message and a prompt with a language model, tools such as web search or calling other tasks and flows, and a memory setting. Kestra describes that memory as carrying context across executions, so subsequent prompts arrive with earlier context attached.

The switch is explicit. The memory setting points at a backing store, with Kestra's KV store as the documented backing option, and it carries a memory ID that identifies which history to use. Give an agent the same ID on every scheduled execution and its context accumulates. Run the same task without that configuration and the agent is working from the current prompt alone.

That design is genuinely useful for one agent doing a recurring job inside Kestra. It also draws its own boundary clearly. The history accumulates under an ID inside one platform's store. Another flow needs deliberate wiring to touch it. Tools outside Kestra, the chat assistant used to question a result, the coding tool used to fix the flow, the agent running in a different automation platform, stand outside that store entirely. A stack with several AI tools ends up with several memories, each partial, none of them the shared past the team actually has.

Logs prove a run happened. They do not brief the next one.

Kestra's execution records are thorough. Statuses, outputs, logs, and timing are all kept, and failed executions can be examined and restarted with care. For operations work, that record is exactly what is needed.

For agent memory, the record answers the wrong question. A recurring agent needs to know what yesterday's execution concluded, what it already sent, and what it promised to check next. Archived outputs become useful only if something loads them and puts the relevant parts in front of the agent. Without that step, the archive and the amnesia coexist in the same system.

A weekly churn watch shows the seams

Take a flow that runs every Monday, pulls accounts showing drop-off signals, and asks an AI Agent task to draft risk notes for the team.

With KV checkpoints, the flow knows which accounts it processed last week, so it does not redo the same pull. With agent memory configured under one stable ID, the drafting agent can remember that one account was already contacted and that another asked for a pause, so its notes reflect the recent past instead of restating first impressions.

Now extend the picture. A daily support-digest agent in another tool spots complaints from one of those accounts on Wednesday. A person asks a chat assistant on Thursday what has been done so far. Neither tool can see the Monday agent's KV-backed history. The knowledge exists, addressed to one flow, in one store, under one ID. Everyone else starts from logs, or from nothing.

One memory, addressed to the whole stack

The pattern worth adding is a memory layer that sits above individual platforms: every scheduled run, on every tool, reads the relevant history before it acts and writes what it learned before it ends. The memory stops being a feature of one orchestrator and becomes shared state for the whole automation practice.

That is the role Vilix AI fills. It is cloud hosted with zero infrastructure to run, and it connects over MCP, so the same memory follows the work across Kestra, other automation platforms, coding assistants, and chat tools. It keeps full conversation history rather than only extracted facts, so the reasoning and corrections behind a result remain available to whichever run needs them next.

Getting started carries no lock-in: a free plan that stays free forever, a 7-day Pro trial that needs no credit card, and the ability to export or delete the data at any time. Keep Kestra for what it does well, scheduling, orchestrating, and observing the runs. Add one shared memory underneath, and Monday's run finally knows what Wednesday's tool learned.