Foundry Agent Memory: Persistence and Shared Project Context

Azure AI Foundry is Microsoft's platform for building and deploying AI agents and applications. The Foundry Agent Service manages threads, which are sequences of messages that an agent can read and respond to. That thread is the primary memory mechanism: the agent knows what happened in the current thread because the messages are there.

Thread memory is scoped to a single conversation and session. It does not automatically carry project decisions, task state, or rules across threads. Tools like fenbs fill that gap by keeping the project record outside the platform, where it is readable by any connected tool and reviewable by people.

How Foundry agents hold state

A thread in the Foundry Agent Service stores messages in order. When the agent processes a new message, the platform provides the thread history as context. The agent's responses appear to "remember" earlier parts of the conversation because the messages are included in what the model receives.

Threads are identified by a thread ID. If you start a new thread, the agent has no memory of the previous one. If you continue an existing thread, the history is available. This means persistence depends on whether you reuse the same thread ID across sessions.

Storage integrations and vector search

Foundry agents can be connected to Azure storage services including Azure Blob Storage, Azure AI Search, and Cosmos DB. These let an agent retrieve information from documents, indexes, or databases as part of a response, rather than relying only on what is in the thread history.

Azure AI Search enables vector search over indexed documents, which means the agent can retrieve semantically relevant content even when the exact words differ. This is useful for a knowledge base or documentation store. It is not a memory system for recording what happened in an agent run; it is a retrieval system for reference material.

How to test what survives a run

Before building logic that depends on state surviving across threads, test the actual behavior. Create a thread, run several exchanges, then start a new thread with the same agent and ask a question that would only make sense if the previous thread was available. If the agent cannot answer without being told, the state does not persist across thread boundaries automatically.

Also test what happens when a thread grows long. As message history accumulates, older messages may be summarized or dropped to stay within the model's context limits. Ask the agent to recall a specific detail from many turns earlier and check whether it is accurate. Summarization can preserve meaning while losing precise wording.

For patterns and terminology around agent memory more broadly, see what is agent memory and how to build agent memory.

Multi-agent setups in Foundry

When you run multiple agents in Azure AI Foundry that work on related tasks, each agent has its own thread history and sees only what is in that thread. There is no built-in shared memory between agents. If two agents need to coordinate, you pass information between them explicitly: one agent's output becomes a message in the other agent's thread, or you load shared state from an external store at the start of each thread.

For a coding workflow where a planning agent breaks a task into steps and an execution agent completes each step, the handoff between them needs to carry the full context: what was decided, what was completed, and what the next step is. Relying on thread history for this works within a session; across sessions, the context needs to be written to and read from a durable store. A shared external record avoids the coupling between agent threads while keeping the handoff data accurate and reviewable by people. It also survives platform updates that would invalidate or archive old thread IDs.

What to keep outside the platform

Project tasks, decisions made by people, standing rules, and where a body of work currently stands are all facts that belong outside any single platform. Keeping them inside a Foundry thread means they are invisible to another tool, another team member, or a thread on a different run.

These facts also require attribution. Knowing that a rule was set by a specific person on a specific date is meaningless if the rule exists only in model-generated thread history, where it looks the same as any other message.

How to do this with fenbs

1. Create a free account and add the project you are building agents for in Azure AI Foundry.
2. Add the project's decisions and rules as Decisions in fenbs. Include who decided them and the reason.
3. Add the active tasks so each Foundry session starts from the current work state rather than guessing.
4. After significant agent runs, record what was completed and what remains in Where we left off.
5. Connect a supported AI tool over MCP from Integrations to give the agent direct access to the project context at session start.

For the security boundaries around what agent memory stores and who can read it, see agent memory security. For how MCP connects an agent to external memory, see agent memory MCP.