Does Flyte Remember Between Runs? Executions Are Recorded and Cached. The Next One Starts With Only Its Inputs.

Short answer: Flyte records a great deal about every execution, and it can reuse a cached task output when the next run matches exactly. A new execution still starts with only the inputs it was given. It does not read the previous execution, absorb what that execution learned, and brief itself before work begins.

That distinction matters more as Flyte workflows gain AI steps. Recording, caching, and remembering are three different jobs. Flyte handles the first two in specific, well-defined ways. The third job belongs to a separate memory layer.

What Flyte actually is

Flyte is an open-source workflow orchestration platform that began at Lyft and now develops with Union.ai. It runs on Kubernetes and was built for ML and data workflows that need to be reproducible at scale. Work is written in Python as tasks and workflows with strongly typed inputs and outputs, registered with a version. Once registered, a version is immutable, so an execution can be traced back to the exact code that produced it.

When a workflow runs, Flyte schedules its tasks as containers, passes typed data between them through its data store, and records the inputs, outputs, and attempts for each step. That record stays available after the run finishes.

What is kept inside one execution

Inside a single workflow execution, Flyte keeps the chain intact:

• Typed data passes from step to step. A task receives the outputs of the tasks before it in the graph, serialized and moved by Flyte rather than passed by hand. A training step, a validation step, and a publishing step in one workflow share one connected run.
• Every step leaves a record. Inputs, outputs, failures, and retry attempts are persisted for each action in the execution. That record is what makes debugging and lineage possible after the fact.
• A failed execution can be relaunched. Fix the failing task, relaunch with the same inputs, and cached steps before the failure do not need to run again when caching applies. The execution resumes from recorded work instead of repeating all of it.

This is real continuity, and it explains why Flyte often gets described as having memory. Within the boundary of one execution, the description is accurate.

What caching does, and what it does not do

Caching is the Flyte feature most often mistaken for cross-run memory, so it helps to be precise about how it works.

Caching is disabled by default and enabled per task, subworkflow, or sub-launch plan. When it is enabled, Flyte builds a cache key from the project, domain, cache version, task signature, and inputs. If a later execution presents the same key, Flyte returns the stored output instead of running the task again. Change an input, change the signature, or bump the cache version, and the key changes and the task runs fresh. Caching is also not available for top-level workflows or launch plans invoked from the UI or CLI.

A cache hit requires an exact match and returns a previous output, unchanged. It does not summarize what happened, carry forward a decision, or warn the next run about a dead end already explored. A cache answers one narrow question: was this exact computation, with these exact inputs, already done? Memory for an agent answers a different question: what should this run know before it starts?

What a new execution starts with

A new Flyte execution, whether launched manually, through the API, or on a schedule, starts from its launch plan. Launch plans are the mechanism for invoking workflows in Flyte. A launch plan binds default or fixed inputs, runtime options, and optionally a schedule, using either a cron expression or a fixed rate. A scheduled launch plan can also pass its kick-off time into the workflow as an input, which is how a daily workflow knows which date window to process.

Everything the new execution knows at start comes from that setup:

• The inputs supplied by the caller or stored in the launch plan
• The optional kick-off time for a scheduled run
• The registered, versioned workflow and task code itself

Nothing in that list includes the previous execution's reasoning, its intermediate findings beyond formal outputs, or context an AI step inside the workflow produced along the way. A person can go and fetch a prior execution's inputs and outputs with FlyteRemote and pass them in manually, and a workflow can be written to read its own history from an external store. Both are plumbing a team builds and maintains. Neither is the platform remembering on its own.

For a pure data pipeline, that boundary is often fine. The pipeline is deterministic, and its inputs tell the whole story. For an AI agent step, the boundary is where work gets repeated. The step wakes up with its typed inputs and no record that the same question was investigated yesterday, a source was ruled unreliable, or a human corrected its approach last week. It produces a fresh answer, sometimes a contradictory one, and the workflow records that too, without connecting the two.

Where a shared memory layer fits

The fix is not to replace Flyte. The orchestration stays: schedules, retries, lineage, and caching keep doing their jobs. The fix is to give the agent steps a place to read context before they run and write context after they finish, in a store that lives outside any single execution and outside any single tool.

That is the role Vilix AI is built for. Vilix AI is cloud-hosted, so there is zero infrastructure to run or maintain. The same memory is available everywhere over MCP, so a Flyte agent step, a coding assistant, and a chat tool can all read and write the same shared state instead of each keeping a private, partial version.

Vilix AI also stores full conversation history, not just extracted facts. When an agent step needs to know why a decision was made, the original exchange is there to revisit, not only a summary of its conclusion. That depth stops the quiet drift where each run sounds confident and each run starts from a slightly different understanding.

Vilix AI has a free plan forever, and Pro offers a 7-day trial with no credit card required. Data stays portable throughout: export everything or delete it anytime.

Get Started for Free Free forever, no credit card.

The bottom line

Flyte remembers an execution the way a good flight recorder remembers a flight: completely, and for inspection after the fact. Inside one execution, state flows between tasks and failures can be relaunched from recorded work. Across executions, caching can return an exact previous output for an exact match, and a new run otherwise starts with only its launch plan inputs.

If a workflow contains agent steps that should learn across runs, that learning needs its own layer. Keep Flyte for orchestration. Add shared memory for the context orchestration was never designed to carry, and the next execution can finally start where the last one left off.