Azure OpenAI Assistants API retires August 26, 2026: the Foundry Agent Service migration guide

Summary. Microsoft retires the Azure OpenAI Assistants API on August 26, 2026. After that date the Assistants surface stops answering calls, and any code that creates assistants, threads, or runs breaks in production. The replacement is the Microsoft Foundry Agent Service, now generally available and built on the Responses API. The migration is not a rename: threads become conversations, runs become responses, create_agent() was removed in azure-ai-projects version 2.0.0, and three tools (Azure Functions, Connected Agents, Deep Research) do not carry over. On Azure, GPT-4.1 still runs at about $2 per million input tokens and $8 per million output tokens as of 2026, with provisioned throughput from roughly $2,448 per month, so the model bill does not change, only the API surface around it. This guide covers the exact code changes, the tool matrix, the Responses-API-versus-Agent-Service choice, and a checklist to finish before the deadline.

The date is fixed and close. Microsoft MVP and Azure architect Stefano Demiliani put it plainly in a public reminder: "On 26 August 2026, Microsoft will retire the Azure OpenAI Assistants API. After that date, the Azure OpenAI Assistants API won't work." That is 24 days of runway from early August, and a non-trivial deployment takes more than a weekend to move and test.

What is changing, and what breaks

The Assistants API was the stateful layer teams used to build agents on Azure OpenAI: it managed threads, stored messages server-side, and executed runs with polling. Microsoft is consolidating that experience into the Foundry Agent Service so there is one supported agent surface instead of overlapping preview and classic APIs. The Microsoft Q&A guidance confirms that the Assistants API specifically retires on August 26, 2026, and that the Agent Service and the OpenAI Responses API are the supported replacements.

Two things break if you do nothing. First, calls to the Assistants endpoints (creating assistants, threads, or runs) stop working. Second, SDK methods that target that surface, including the older create_agent(), fail because they were removed in the 2.0.0 SDK. Microsoft is consolidating the older classic agent experience on a separate schedule, but the Assistants API date is the one that takes down running code first, so treat August 26, 2026 as the hard deadline.

Assistants API vs Foundry Agent Service

The new service keeps the identity, governance, and observability you already rely on, then changes the API primitives underneath. This table maps the old model to the new one.

The practical read: conversations can hold more than messages (tool calls, tool outputs, and other items), and responses replace the run-and-poll loop with a single call that takes input items and returns output items. Context is retained automatically across calls, which removes a chunk of the plumbing teams wrote by hand under the Assistants model. For a longer view of where this fits, see how enterprise AI agents move to production and the governance layers around them.

The three code changes that matter

Install the current SDK first. The migration guide pins the package at 2.0.0 or later:

            pip install "azure-ai-projects>=2.0.0"
          

Then initialise both clients. Agent creation and versioning stay on the project client; conversations and responses use the OpenAI client you get from project.get_openai_client():

            from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

PROJECT_ENDPOINT = "https://your-resource.services.ai.azure.com/api/projects/your-project"

project = AIProjectClient(endpoint=PROJECT_ENDPOINT, credential=DefaultAzureCredential())
openai = project.get_openai_client()
          

1. Assistants become versioned agents

The old client.beta.assistants.create() call is replaced by project.agents.create_version() with a structured PromptAgentDefinition that carries explicit model, instructions, and tools fields.

            # Before: Assistants API
assistant = client.beta.assistants.create(
    model="gpt-4.1",
    name="my-assistant",
    instructions="You help with math questions. Use Code Interpreter to visualize numbers.",
    tools=[{"type": "code_interpreter"}],
)

# After: Foundry Agent Service
from azure.ai.projects.models import CodeInterpreterTool, PromptAgentDefinition

agent = project.agents.create_version(
    agent_name="my-agent",
    definition=PromptAgentDefinition(
        model="gpt-4.1",
        instructions="You help with math questions. Use Code Interpreter to visualize numbers.",
        tools=[CodeInterpreterTool()],
    ),
)
          

The new response returns an agent.version object with an id and a version field, so agent definitions are now versioned artifacts you can promote and roll back.

2. Threads become conversations

Threads stored messages. Conversations store items, which include messages, tool calls, and tool outputs. Create them on the OpenAI client:

            # Before
thread = client.agents.threads.create()
message = client.agents.messages.create(
    thread_id=thread.id, role="user", content="Draw a line with slope 4 and intercept 9.")

# After
conversation = openai.conversations.create(
    items=[{"type": "message", "role": "user",
            "content": "Draw a line with slope 4 and intercept 9."}]
)
          

3. Runs become responses

Runs were asynchronous processes you polled until they reached a terminal state. Responses take input items and return output items in one call, optionally tied to a conversation for stored context:

            # Before: create a run, then poll
run = project_client.agents.runs.create(thread_id=thread.id, agent_id=assistant_id)
while run.status in ("queued", "in_progress"):
    time.sleep(1)
    run = project_client.agents.runs.get(thread_id=thread.id, run_id=run.id)

# After: one response call
response = openai.responses.create(
    conversation=conversation.id,
    extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}},
    input="Please address the user as Jane Doe. The user has a premium account.",
)
for item in response.output:
    if item.type == "message":
        for block in item.content:
            print(block.text)
          

One common error to expect: calling conversations.create() on the project client raises AttributeError: 'AIProjectClient' has no attribute 'conversations'. Conversations and responses live on the OpenAI client from project.get_openai_client(), not the project client.

Which tools carry over, and which are gone

This is where migrations quietly fail. Most tools carry over, but three that teams use in production do not, and two useful ones are new. Check your agent definitions against this before you assume a lift-and-shift.

If your agents call Azure Functions as a tool, that pattern needs a redesign, because it is not offered in the new service. Connected Agents move to the Workflow model and the Agent-to-Agent tool, and Deep Research shifts to a Deep Research model paired with the Web Search tool, which is itself now generally available. Model Context Protocol tool calling graduated from preview to GA, so MCP-based integrations are on firmer ground than before.

The migration tool does not move your data

Microsoft ships a migration tool on GitHub (also reachable at aka.ms/agent/migrate/tool) that rewrites code constructs: agent definitions, thread creation, message creation, and run creation. It is a real time-saver for the mechanical rewrite. It has one important limit stated in the official migration guide: it does not migrate state data such as past runs, threads, or messages.

In plain terms, you get new code, not new history. After migration you start fresh conversations, and any historical thread data stays reachable through the previous API only until that surface is deprecated. If your product depends on long-lived conversation history, export what you need before August 26, 2026, because the read path disappears with the API.

Foundry Agent Service or the OpenAI Responses API?

The Agent Service is not the only supported path. If your workload is pure model inference, the OpenAI Responses API alone is lighter and closer to the metal. The two choices split cleanly by need.

Because the Agent Service is a superset of the Responses API, teams that start with plain responses can add hosted tools later without another rewrite. Teams that need non-OpenAI models, single-tenant storage, or role-based access on one Azure bill get more from the Agent Service. This mirrors the way Azure Foundry consumption-unit pricing is structured for multi-model workloads, and it is the same decision teams faced when OpenAI shut down its own Assistants API in favour of the Responses API.

A migration plan that finishes before the deadline

Treat this as a scoped project, not a config toggle. A workable sequence for a production workload:

1. Inventory every service that calls the Assistants API, and flag the tools each agent uses against the table above. Azure Functions, Connected Agents, and Deep Research need redesign, not a rewrite.

1. Pin azure-ai-projects>=2.0.0 in a branch and run the migration tool on a copy of the code.

1. Replace create_agent() and beta.assistants.create() with create_version() and PromptAgentDefinition; move thread and message code to conversations; move run-and-poll code to responses.create().

1. Export any conversation history you must retain, since the tool does not move state data.

1. Verify: confirm create_version() returns an id and version; create a conversation, send a response, and check output items return; send multiple responses to the same conversation and confirm context is retained.

1. Load-test and cut over well before August 26, 2026, keeping the old path only until the new one is proven.

The real cost here is usually the tool redesign and the state export, not the SDK swap. The three lost tools are what turn a one-day change into a multi-week project, so scope them first.

Costs after migration

The API changes; the model bill does not. On Azure, GPT-4.1 is priced at about $2 per million input tokens and $8 per million output tokens as of 2026, and provisioned throughput units start near $2,448 per month for sustained traffic, which can cut per-token cost for high-volume workloads. What is new is where state lives: the Agent Service uses single-tenant storage, with the option to bring your own Azure Cosmos DB, so storage of conversation items becomes a line you own and can size.

India-specific considerations

The deadline is worldwide: August 26, 2026, applies the same in Bengaluru as in Seattle. For Indian teams, two points matter. Map data flows to the Azure regions you actually deploy in, and handle any personal data in conversation items under the Digital Personal Data Protection Act, 2023. Single-tenant storage and bring-your-own Cosmos DB make it easier to keep conversation state inside a chosen region during and after the move, which supports data-residency commitments. For the wider engineering view, see the DPDP engineering playbook for Indian teams. Enterprises with regulated data can also weigh how model choice and control play out on Azure.

FAQ

How eCorpIT can help

eCorpIT runs Azure AI migrations as scoped engineering projects: inventory the Assistants API surface, redesign the tools that do not carry over, run the SDK migration, and verify conversations and responses under load before the deadline. Our senior engineering teams are ISO 27001:2022 certified and design applications aligned with DPDP Act 2023 requirements, so conversation state and personal data stay handled correctly through the cutover. If your team has Assistants API workloads to move before August 26, 2026, talk to us and we will map the work to the time you have left.

References

1. Microsoft Learn — Migrate to the new Foundry Agent Service

1. Microsoft Q&A — Will the Azure OpenAI Assistants API be deprecated on August 26?

1. Microsoft Q&A — Will the azure-ai-agents SDK continue after the Assistants API retirement?

1. GitHub — agent-migrator: Assistants to Agent Service migration tool

1. Microsoft Azure — Azure OpenAI Service pricing

1. CloudZero — Azure OpenAI pricing in 2026

1. Stefano Demiliani — reminder on the Assistants API retirement date

1. GMI Cloud — OpenAI Responses API vs Azure AI Foundry

1. AZ365 — Azure AI Foundry vs Azure OpenAI: the 2026 decision

1. Microsoft Learn — Azure AI Agents client library for Python

1. Microsoft Learn — Assistants API concepts (classic)

_Last updated: August 2, 2026._