Assistants API vs. Foundry Agents

Question

Assistants API

Our setup: 2x master Assistants created in Foundry Classic + many user threads created @ runtime in-app for respective Assistant.

Problem:

1.1 When user requests to plot a graph/make plan (PDF) -> 1st assistant creates a file & saves in "Data files" (shared resource, as seen from Classic Foundry) but is unable to retrieve it to display in-app.

1.2 Refer attachment. Graphs are saved in root whereas PDFs in /mnt/data/... Not sure why 2 different path. This also causes issues in retrieval.

1.3 2nd Assistant is unable to create any files etc.

Question:

2. Do we have to attach memory explicitly? To each thread? or To each Assistant?
3. We created respctive vector stores for each assistant & referenced the store ID but Assistant doesn't save file in their vector store. Appears to only use that to read content (of files we've uploaded) for RAG

Foundry Agents:

4.1 We're considering migrating the setup to Foundry Agents (prompt agents). 2 master agents (or more soon) created in Foundry and conversations per user created in-app for respective agent. Similar to Assistants setup above.

4.2 Do we attach memory to each Agent? Or to each conversation?

4.3 When memory attached to an agent with many simultaneous conversations, is there a risk of data or asset/resource leak between conversations? Data of user 1 displayed to user 2 accidentally? If yes, what are the recommendations to mitigate/prevent such risk?

4.4 Using tools, when agents plot graphs or make plans (PDFs), how do we retrieve these files & display to user? Where is such content saved? In conversation memory (if exists)?

Thanks & appreciate your help with this.

Answer 1

Hi GenixPRO

Thanks for your detailed question. This is a common confusion when working with Assistants API and moving to Foundry Agents. Let me try to clarify both behavior and your issues step by step.

1. About memory and vector stores in Assistants API

In Assistants API, you do not need to attach memory separately.

• Memory is already handled by the Thread
• Thread stores the conversation history automatically
• You simply keep adding messages to the same thread

So, no need to attach memory to:

• assistant
• thread separately

This is expected behavior.

Now about vector stores:

• Vector stores are only used for file search (RAG scenarios)
• They are used to read and search content from uploaded files
• They are not used to store generated files like PDFs or charts

So, if your expectation is that generated files will be saved into vector store, that will not happen.

2. Why your generated files are not retrievable

When using tools like code interpreter:

• Files (like charts or PDFs) are generated during the run
• These files are stored temporarily as part of the tool execution
• They are not automatically persisted for reuse later

That is why:

• your first assistant creates files but cannot retrieve later
• second assistant cannot access those outputs

This is a limitation of the Assistants API design.

3. Important point about Assistants API

The Assistants API is being retired, so this behavior will not be improved further.

You can check here: Assistants API concepts and deprecation notice [learn.microsoft.com]

Microsoft recommends moving to Foundry Agents.

4. How Foundry Agents solve this better

Foundry Agents are designed as a more complete system:

• They manage conversations (threads) automatically
• They support tools and workflows in a more structured way
• They allow better integration with storage and enterprise data

They also give you more control for:

• where data is stored
• how tools execute
• how outputs are managed

Agents are built as a full platform instead of just an API layer. [dev.to]

If you stay on Assistants API:

• Do not rely on vector store for generated files
• Capture generated file output in your application code
• Store files externally (blob storage or database)
• Pass file references back to users

If you move to Foundry Agents:

• Treat agent as a long running service
• Use external storage for generated outputs

Design flow where tool output is saved and returned explicitly

This should help explain the behavior you are seeing. Do let me know if you have any further queries.

Thankyou!