Azure Open AI Assistants APIs deprecated. Transition help required.

Question

Hi Team,

We've used Open AI Assistants APIs to:

1. Create centralized agents in Foundry (classic) with system instructions, tool use, functions etc. - Backend
2. Our frontend mobile apps use the assistant_id created in #1 to then create individual threads @ runtime for each user. Relevant context is loaded to thread for conversation.

Having to move to Microsoft Foundry Agent Service due to deprecation of Assistants APIs, how can we replicate steps above?

1. Our understanding is that frontend will be required to create agents directly @ runtime (instead of #1). Is there a way that we define standard instructions + tool def. etc. once in Foundry and instance of this master agent ge created @ runtime? How can we achieve this?
2. Are the messages in agent conversations stateful or do we need to attach memory/db for state?

Thanks.

Answer 1

Hi GenixPRO,

Thanks for your question. This is a good topic because many people are confused about the Assistants API changes.

First, what is happening:

OpenAI has announced that the Assistants API will be deprecated and will be fully removed on August 26, 2026. After that date, any calls to Assistants endpoints will stop working. [ragwalla.com]

For new development, OpenAI is moving everyone to a newer API called the Responses API, which is simpler and more flexible for building AI applications.

Now coming to Azure side:

If you are using Azure OpenAI, there is no immediate impact today. Azure OpenAI uses its own APIs and is not directly dependent on OpenAI Assistants API. [learn.microsoft.com]

So, your existing Azure OpenAI applications will continue to work normally for now.

However, it is still a good idea to understand the transition and plan ahead.

What changed conceptually:

Earlier Assistants API had multiple components like assistants, threads, and runs.

In the new approach:

Assistants are replaced by prompts Threads are replaced by conversations Runs are replaced by responses

Everything is simplified into a single flow where you send input and get output. [developers...openai.com]

This means less complexity and easier management in future designs.

What you should do in your scenario:

If you are building directly on OpenAI platform You should start planning migration to Responses API soon because Assistants API will be removed in 2026.

If you are using Azure OpenAI, You can continue using it as usual. But for new designs, it is better to follow newer patterns like chat completions or responses style APIs so that your solution stays future ready.

Basic guidance to move forward:

Review your current implementation and check if you are using Assistants concepts like threads and runs Start designing your flow using simple request and response pattern instead of managing multiple objects Keep conversation history on your side when needed instead of depending on server stored threads Watch official updates from Microsoft because Azure may introduce aligned features later

In Short: Nothing is broken right now Assistants API is going away in OpenAI platform. New standard is Responses API Azure OpenAI is still stable, but you should design with future approach

Official reference you can check for more details:

OpenAI migration guide https://developers.openai.com/api/docs/assistants/migration

I Hope this helps. Do let me know if you have any further queries.

Thankyou!

Answer 2

I think u keep one master agent fixed in Foundry and spin a clean convo per user; that’s the straight swap for the old assistant_id + thread flow. and if it still drifts, re‑init that convo with bare ctx—cuts the bleed fast.

Answer 3

For scenarios built on Azure OpenAI Assistants in Foundry (classic), the replacement is the Microsoft Foundry Agents service. Assistants are deprecated and will be retired on August 26, 2026, and workloads should be migrated to Agents.

The classic Assistants model used:

1. A centrally defined Assistant (system instructions, tools, functions, files, etc.).
2. Per-user Threads created at runtime by the frontend, using the shared assistant_id.

In the new model:

1. Central definition moves to an Agent definition
   • Use the Microsoft Foundry Agents service to define an agent once with:
     • Instructions (equivalent to system prompt/personality).
     • Tools (Web Search, File Search, Code Interpreter, MCP tools, OpenAPI tools, custom tools via function calling, etc.).
     • Model selection and other configuration.
   • This replaces the “centralized assistant” in Foundry (classic).
   • Agents are versioned; use project for agent creation and versioning.
2. Conversations replace Threads
   • The new agents experience uses “conversations” instead of classic “threads and messages” for state management.
   • State is automatically retained across calls.
   • Old thread data is not migrated; new conversations must be started after migration. Historical data remains accessible only through the previous API until it is deprecated.
3. Backend/Frontend split in the new model
   • Backend:
     • Define and manage the agent (the “master” configuration) in Foundry using the Agents service.
     • Use the project client for agent lifecycle and versioning.
   • Frontend/mobile apps:
     • Do not need to create full agents at runtime.
     • Instead, they:
       • Call the published agent endpoint (see migration guidance for agent applications to the new agent endpoint format).
       • Create and continue conversations for each user, passing user-specific context as conversation input.
4. Reusing a single “master” agent definition
   • The new Agents service explicitly supports defining an agent once and executing it many times with different inputs:
     • “Separation of duties. Define agents once and execute them with various inputs.”
     • “Deployable agents. Agents can be exposed as individual endpoints.”
   • This matches the requirement to avoid redefining instructions and tools on the frontend.
   • At runtime, the frontend simply:
     • Targets the agent’s published endpoint.
     • Starts a new conversation per user (or per session) and sends user context/messages.
5. Endpoint changes when migrating from classic agent applications
   • If the current frontend calls a classic Agent Application endpoint, update it to the new Agents endpoint format:
     • Responses:
       • Legacy: .../projects/{project}/applications/{app}/protocols/openai
       • New: .../projects/{project}/agents/{agent}/protocols/openai/v1/responses
     • Activity:
       • Legacy: .../projects/{project}/applications/{app}/protocols/activityprotocol
       • New: .../projects/{project}/agents/{agent}/protocols/activityprotocol
   • During transition, some agents may still show the legacy publishing UX; new agents (with agent.identity set) use the new publishing experience and stable endpoints.
6. SDK usage pattern
   • Use the project client to obtain an OpenAI client for conversations and responses:
     • JavaScript example:

              import { AIProjectClient } from "@azure/ai-projects";
              import { DefaultAzureCredential } from "@azure/identity";
              
              const projectClient = new AIProjectClient(
                  process.env["PROJECT_ENDPOINT"],
                  new DefaultAzureCredential()
              );
              const openAIClient = await projectClient.getOpenAIClient();
       

   • Use project for agent creation/versioning and openai for conversations/responses.
7. Common migration pitfalls
   • Old methods like create_agent() are removed in v2.0.0 of the SDKs; use create_version() (or language-specific equivalents) with a PromptAgentDefinition when defining agents.
   • Ensure the correct client is used:
     • For conversations, always obtain the OpenAI client from the project client (get_openai_client / getOpenAIClient), then call the conversations/responses APIs.

Putting it together for the described architecture:

• Backend:
  • Define a single Agent in the new Agents service with the standard instructions, tools, and model configuration.
  • Manage versions and publishing from Foundry.
• Frontend:
  • Stop creating agents at runtime.
  • For each user/session, create a new conversation against the published agent endpoint and send user context/messages.
  • This reproduces the “one shared assistant, many per-user threads” pattern using “one shared agent, many per-user conversations.”

---

References:

• Migrate to the new agents developer experience
• Azure OpenAI Assistants API (Preview) (classic)
• Getting started with Azure OpenAI Assistants (Preview) (classic)
• How to use the OpenAPI spec tool (classic) (python)
• Migrate from agent applications to the new agent endpoint and publishing experience