Azure Retired Its Assistants API

Part of a series on running AI workflows across model providers — this one is about a retirement that already happened, not one still coming.

Unlike the other API-transition articles in this series, this one isn't a warning about something coming up — it already happened. Azure OpenAI's Assistants API retired on August 26, 2026. If you built anything on it and haven't dealt with the migration yet, this article is about what to check right now, not what to prepare for eventually.

What retired, and what replaced it

The Assistants API was Azure's (and OpenAI's) earlier framework for building stateful, tool-using AI assistants — threads, runs, built-in retrieval, and code interpretation bundled into one API surface. As of August 26, 2026, that API stopped accepting new usage. Its replacement is the Foundry Agent Service, Microsoft's current agent-building platform, built on the broader Foundry consolidation covered in the previous article.

Worth noting precisely: there's a "classic" variant of the Foundry Agent Service that itself has its own later retirement date — March 31, 2027 — so even the replacement isn't the final resting point for teams building on this stack today. If you're migrating now, it's worth checking whether you're being pointed at the classic Foundry Agent Service or the current one.

Two retirement dates on the same migration path — worth confirming which target you're actually migrating to.

If you haven't migrated: what to check first

Identity and authentication handling. The migration guide's own caution here is specific — auth flows that worked against the Assistants API need to be re-tested against the Foundry Agent Service rather than assumed to carry over unchanged.

Data persistence assumptions. Service-generated IDs (thread IDs, run IDs, and similar) shouldn't be assumed interchangeable between the old and new systems. Anything in your application that stored or referenced those IDs directly needs review.

External integrations. Anything connected to your Assistants API implementation — webhooks, downstream services expecting a particular response shape — needs reconnection and validation against the new service, not just a configuration swap.

Microsoft does provide a documented migration guide and a migration tool that automates part of the move, which is worth using as a starting point. But the tooling's own limitation is stated plainly in Microsoft's guidance: it "cannot eliminate application testing." Treat it as a head start, not a finished migration.

Why this matters even if you never used the Assistants API directly

If your AI infrastructure has been built entirely through DNotifier rather than by calling Azure's Assistants API directly, this specific retirement doesn't touch your application — DNotifier's defineAgent() and Workflow abstractions were never built on top of the Assistants API in the first place, so there's nothing here to migrate.

The reason this is still worth knowing is the same reason Perplexity's Sonar API Is Retiring covered Perplexity's Sonar retirement: it's a live, concrete example of how often major AI infrastructure providers change their surface-level APIs, sometimes on short notice, sometimes with real migration cost attached. Two different providers in this series, covered in two different batches, have each had a real, dated API-level retirement in the same several-month window. That's not a coincidence specific to either provider — it's closer to the normal pace of change in this part of the industry right now.

A use case that shows the practical difference this makes

A team had built an early internal support-triage tool directly against Azure's Assistants API, before DNotifier was introduced elsewhere in their stack. When the August 26 retirement date arrived, that tool needed real migration work — new auth testing, ID handling changes, and re-validated integrations, taking the team the better part of a week. Meanwhile, a newer customer-facing assistant the same team had built through DNotifier's defineAgent() pattern, calling Azure AI via provider: "azure_ai", needed no changes at all — the retirement happened entirely underneath an abstraction layer that was never coupled to the specific API surface that went away.

Same retirement event, two very different amounts of work — depending on what sat between the application and the API that changed.

Frequently asked questions

Is it too late to migrate if I missed the August 26 date?

The retirement means the old API stopped accepting new usage as of that date — if you have an implementation still depending on it, treat migration as urgent rather than optional at this point, using Microsoft's migration guide and tooling as a starting point.

Does this affect DNotifier's Azure AI integration?

No — DNotifier's Azure AI provider was never built on the Assistants API specifically, so this retirement doesn't require any change to a DNotifier-based Azure AI integration.

What's the difference between the Foundry Agent Service and its "classic" variant?

The article's sourcing didn't detail the functional differences beyond the different retirement dates (the classic variant retires March 31, 2027) — worth checking Microsoft's current documentation directly if you're deciding which one to build on today.

Should I expect more retirements like this from Azure specifically?

Given how actively Microsoft has been consolidating and renaming its AI platform (covered in the previous article), yes — this is a reasonable expectation to build into any Azure-dependent architecture, which is part of the argument for routing through an orchestration layer covered later in this series.

The Bottom Line

Next in this series: separate from one-time API retirements, Azure runs an ongoing, scheduled process for retiring individual models — here's how that process actually works.

Read part four: How Azure Retires AI Models. Explore dnotifier.com.