Does Azure Durable Functions Remember Between Runs?

Inside one orchestration, yes. Between separate runs, no. An orchestrator rebuilds its local state by replaying its own history every time it wakes, so a single long-running instance never loses its place. A new instance, started by a timer or a queue message, begins with only its input. It does not open the previous instance's history, read its conclusions, or inherit its variables.

The statefulness is real, and scoped to one instance ID.

How does one orchestration remember where it was?

Orchestrator functions use event sourcing. Instead of storing a snapshot of current state, the Durable Task Framework records an append-only history of everything the orchestration has done: activities completed, timers fired, external events received, and the results each step returned.

Progress is checkpointed at each await in C# or yield in JavaScript and Python. New events are appended to storage in the task hub, by default Azure Storage tables, queues, and blobs. The process is then free to unload or recycle.

When more work arrives, the orchestrator wakes and re-executes from the first line. During replay, completed calls are answered from history instead of running again, so local variables rebuild to exactly where execution left off. Microsoft puts the payoff plainly: local state is not lost when the process recycles or the virtual machine reboots. The price is determinism: orchestrator code must make the same calls on every replay, so dates, random values, and direct input and output belong in activity functions.

What does the next instance start with?

A new instance starts with a new history. Its starting knowledge is the orchestration code, its configuration, and the JSON input passed when the instance was created. Nothing else carries across automatically.

Consider a timer-triggered agent that checks open support cases every morning. Monday's instance reads the cases, calls an AI activity to classify each one, and decides that one customer is waiting on a replacement part, not an answer. That decision lives in Monday's history. Tuesday's instance is a different instance. Unless Monday's run wrote that decision somewhere Tuesday's run is told to read, Tuesday classifies the same case from the raw text again and can reach a different conclusion.

The finished instance's history still exists in storage for a person to inspect. Inspection is not inheritance: it is never fed into the next instance as context.

What about durable entities?

Durable entities are the part of Durable Functions designed for state that outlives a single orchestration. An entity is a small stateful actor addressed by type and ID, for example a counter or a per-customer tally. Entities process operations one at a time, in order, and their state is persisted as JSON, so a later orchestration can read a value an earlier run updated.

Entities remember between runs, within tight boundaries. The state is a value designed in advance, under one entity ID, inside one function app and task hub. An entity can hold that a customer has been contacted three times. It does not hold the conversation that explains why the third contact changed tone, or what a person in another tool decided in between. Anything richer must be modelled and read back by your own code, operation by operation.

What does continue-as-new do to memory?

A loop that never ends builds a history that never stops growing, and replay slows as the history grows. The eternal orchestration pattern answers with continue-as-new: the orchestrator restarts under the same instance ID, its history resets, and only the JSON value passed as the new input carries into the next generation.

Everything the next generation knows is what the current generation remembered to pack into that one value. Whatever was learned but not packed is gone by design. The framework remembers execution. Carrying knowledge forward is your code's job.

How do operators carry knowledge between instances today?

Working patterns move knowledge out of the orchestration and into something a new instance can be pointed at:

1. Pass it as input, when the starter of the next instance already knows the value.
2. Store it in a durable entity, when the knowledge is a small value keyed by an ID.
3. Write it to an external database, table, or blob from an activity, and read it back at the start of the next instance.
4. Keep it in custom status fields for people to query.

These patterns share a shape: memory stays inside one function app, in a schema designed in advance, holding values rather than the reasoning behind them.

What kind of memory does a scheduled AI agent actually need?

An AI activity changes what the next run needs. The valuable output is rarely a counter. It is a judgement: this lead already replied and asked for pricing next quarter, this incident was traced to a deploy on Friday, this customer corrected the summary twice. The next run needs that judgement with its full context, available to the other tools doing related work, not only to one orchestration in one task hub.

How does Vilix AI give a scheduled agent a memory outside the orchestration?

Vilix AI is a cloud-hosted memory layer outside any single automation tool, so there is no infrastructure to run alongside your function app. A scheduled agent connects to Vilix AI over MCP. At the start of a run it retrieves the relevant saved context, and at the end it saves what it did and decided.

Vilix AI stores full conversation history, not just extracted facts and counters, so the next run can revisit what was actually said and decided. Because the memory belongs to your Vilix AI account rather than to one orchestration, the same memory is available everywhere: the scheduled agent, a session in another AI tool, and the next automation you build on a different platform. The plan is free forever, with a 7-day Pro trial that needs no credit card. You can export or delete your data at any time.

Durable Functions gives one orchestration a memory for its own execution. Give the agent a memory that spans instances and tools, and each new run starts from what every earlier run learned.

Frequently asked questions

Does an orchestrator lose its local variables when the process recycles?

No. At each await or yield, the framework checkpoints the history to durable storage. On wake, the orchestrator replays from the start and completed calls are answered from history, so local variables rebuild to where execution paused.

Does a new Durable Functions instance read the previous instance's history?

No. Each instance has its own history. A new instance begins with its code, its configuration, and the input it was given. A previous instance's history remains in storage for inspection, and it is not loaded as context for the next instance.

Can a durable entity remember state between runs?

Yes, within its design. An entity persists a small JSON state under its entity ID and processes operations in order, so a value written by one run can be read by a later run. The state holds values you model in advance, not conversation history or reasoning.