Does Azure AI Foundry Remember Between Runs? What Threads Actually Keep

In the Azure AI Foundry Playground, your agent feels like it has a memory. Then you connect it to a scheduled job or a webhook, and every run acts like the previous one never happened. Same agent, same code, different behavior.

There is a precise technical reason for the difference, and it comes down to what Foundry threads are and what they are not.

The short answer

Inside one thread, yes: the agent remembers the conversation. Threads persist server-side, and a conversation can be resumed by reusing the same thread ID, even across application restarts.

Across threads, no: a new thread starts with no knowledge of any previous thread. There is no built-in shared memory across threads and no built-in long-term semantic memory. Microsoft's own guidance says it plainly: agents keep context within session-specific threads, and carrying memory across sessions means manually reusing the thread ID, because long-term memory is not built into the service.

The real question is never "does it remember." It is "does your run reuse a thread, or does it silently start a new one?"

What a thread is

A thread is Foundry's unit of conversation memory. Every message and agent run attaches to a thread, stored server-side: by default in a Microsoft-managed storage account, or in your own Azure Storage account with Bring Your Own Storage for tighter control over data management and compliance.

Within a thread, the agent sees the full conversation history. The Playground feels good for exactly this reason: every message in a Playground session belongs to the same thread.

Threads resume by reusing the thread ID, but they do not clean themselves up. They must be deleted explicitly, or unused threads accumulate storage in production.

The boundary: a thread is conversation memory. It holds what was said, and it shares nothing with a different thread.

Why scheduled runs wake up blank

A scheduled job has no session to inherit a thread from. When a timer-triggered function calls your agent, the code typically creates a fresh thread, does its task, and ends. If last night's run concluded "the vendor feed is flaky on Tuesdays," tonight's run cannot know, because that conclusion sits in a thread tonight's run will never open.

Webhooks fall into the same trap. Each invocation creates a new thread, so the agent has no memory of previous steps. The standard fix is manual thread ID management: create the thread once, store the thread ID keyed by user or session in Redis or Cosmos DB, and attach every call to that stored thread.

For scheduled automation the honest version is harsher. A nightly job usually needs operational memory, not a conversation to continue: which items it already processed, which alerts it already sent, what it decided last time. Threads were not designed for that. They record dialogue; they do not distill conclusions.

The stateless fine print

Foundry treats each run as independent, and that has a few consequences automation builders meet in production.

First, conversation memory and operational memory are different things. A thread remembers what was said, not what the agent learned while working, and nothing is extracted across threads automatically.

Second, state does not cross thread boundaries. Monday's run in thread A and Tuesday's run in thread B share nothing. Summaries and decisions do not travel on their own.

Third, resource hygiene is your job. Temporary references created in one run can be cleaned up before the next run touches them, which appears as mysterious failures on the second run. Threads themselves pile up unless you delete them.

None of this is a bug. It is a stateless compute model with conversation-scoped persistence. The pain is the mismatch: builders expect the agent to remember like a colleague, and the platform remembers like a chat log.

What builders wire up today

Three patterns cover most of what teams build.

The lightest is thread ID persistence: store one thread ID per job or user in Redis or Cosmos DB and reuse it every run. You get continuity, plus an ever-growing thread that eventually needs truncation or summarization.

The middle option is an explicit state store: each run ends by writing a structured record of what was processed, decided, and observed; the next run reads it back. You design the schema and retention yourself.

The heaviest is retrieval-based long-term memory: embeddings of past runs in Azure AI Search or another vector database, pulled back as context when relevant. This is the only approach that scales to "remember what mattered from any past run," and you build it entirely yourself.

All three work. All three are infrastructure you own, monitor, and pay for: the extra store, the extra code paths, the debugging sessions when a run reads stale state.

The alternative: memory as a service

Every one of those patterns is the same story: the agent platform stopped at conversation state, so the team built the memory layer themselves. That layer is never the product, but it consumes product hours.

Vilix AI is built to absorb that work. It is cloud-hosted, so there is nothing to deploy and no infrastructure to manage: no Redis cluster, no database containers, no vector index to tune. Because it connects over MCP, the same memory follows your agent everywhere: the scheduled job, the webhook handler, and the chat interface all read and write one shared memory instead of a thread per run that never talks to the others.

It stores full conversation history, not just extracted facts, so the agent revisits what actually happened instead of a summary of a summary. Free forever on the free plan, with a 7-day Pro trial that asks for no credit card, and your data stays portable: export everything or delete it at any time.

The pitch is simple because the problem is: your agents forget everything between runs. Give them one memory, and stop rebuilding thread plumbing for every new automation.

This week's checklist

If your agents run on Azure AI Foundry, check three things. First, find out whether each automation reuses a thread ID or creates a new one per run; usually it is a new one, and that is the whole bug. Second, decide what kind of memory the job actually needs: scheduled work usually needs decisions and observations, not chat history, and threads were not designed for that. Third, pick your persistence shape deliberately: thread reuse for simple continuity, an external store for run decisions, vectors for long-term recall.

Or skip the plumbing. Point your agent at a memory layer that already exists: Vilix AI.

Foundry threads remember the conversation. The learning, the continuity, the state across runs: that is on you. Decide where that state lives now, and your agent will stop waking up a stranger.