# The Assistants API is dead, and clients' chat history may go with it

> Moving to the Responses API looks like an endpoint swap, but the tool-calling loop and conversation storage now live in the client's own code.

Original: https://fdetimes.net/en/analysis/assistants-api-shutdown-responses-migration/

OpenAI's migration guide now opens with a sentence in the past tense: the Assistants API was officially shut down on 26 August 2026 and can no longer be used. This is no longer a warning. Any application still calling the API is broken; it may just be that nobody has noticed yet.

There was no shortage of time to prepare. On 26 August 2025, OpenAI announced on its developer forum that it was deprecating the Assistants beta and would switch it off exactly one year later. Even so, for a project in the "working fine, no need to touch it" state, a year passes easily without anyone looking at it.

If you want to work as an FDE, picture a ticket like this: a client has a chatbot or an internal agent that someone built last year. It now returns errors, and the person who wrote it has left. At first glance it looks like a matter of changing the endpoint. In practice, the hard part lies in the data and in the systems that read the output downstream.

## Why did OpenAI drop Assistants?

OpenAI describes Assistants as an early attempt at building agents, before reasoning models existed. The Responses API is presented as the recommended integration path, now and for the long term. According to the migration guide, clients who move get better performance plus built-in tools such as web search, MCP and computer use.

But switching to Responses brings more than new features. In the way OpenAI maps the concepts, the tool-calling loop now lives in the client's code, and any old history the client wants to keep using must be stored by the client. Responses hands control back to you, so you also take on work you never had to think about before.

## Three concepts renamed, three responsibilities moved

OpenAI's guide maps the concepts in pairs. Assistant becomes Prompt: a configuration of model, tools and instructions that is easier to version and update. Thread becomes Conversation, which stores a sequence of items rather than just messages; Run becomes Response, and the tool-calling loop is now controlled by the client's own code.

Read line by line, none of this looks alarming. The risk only shows when each pair is set against the question "who has to do what differently at the client?" The table below takes that approach:

| Assistants | Responses | What the FDE must check at the client |
|---|---|---|
| Assistant | Prompt (model, tools, instructions, versioned) | Is the configuration hard-coded or on the dashboard? Who can edit it, and how do they roll back? |
| Thread | Conversation (a sequence of items, not just messages) | Has the client stored old history separately? How much is kept after the move? |
| Run | Response, with the tool loop controlled by the client's code | Can the client's code handle function calls, retries and a cap on the number of iterations? |
| Output contains only messages | Output adds activity items (file search, function call) | Do downstream parsers, logs, dashboards and CRM understand the new item types? |

The second and last rows are the ones most likely to cost a client data or trust. The next two sections deal with each in turn.

## Conversation history: what cannot be recovered

OpenAI's guide is explicit: the Assistants call for retrieving a thread's messages no longer works; use the messages you stored yourself. Put simply, if the client always treated OpenAI's threads as its database, then after 26 August 2026 any history that lived only in those threads can no longer be retrieved.

Imagine a logistics company using Assistants as a customer-service bot. Each complaint is a thread, and staff reopen the thread to read the whole exchange before phoning the customer.

If the backend stored only the thread_id and not the content, that screen is now empty, and the problem is no longer the API but the company's business process itself.

Even a careful vendor cannot carry everything over. Zoho SalesIQ migrated its own integration, so customers' existing Assistant IDs, conversation IDs and file IDs still work within the SalesIQ-managed integration. But when migrating a conversation, SalesIQ brings along only the 100 most recent messages.

Picture a support conversation that has run for weeks and reached 340 messages: on the new system it has 100, and the 240 oldest fall outside the context the model can see. If key details such as a contract number or a refund commitment sit in those early messages, the new bot will answer as if it had never heard of them.

**Key point:** Changing the API is the small part of this migration; the large part is answering where the client's conversation history actually lives.

So the first job at the client is not writing code. Take an inventory: which conversations the client has stored separately, which survive only as IDs, and which business processes need the full history rather than just the most recent portion.

Then agree in writing with the client how much is enough to keep, rather than letting a default number decide for them.

## The tool loop is now your code

OpenAI's guide makes clear that with Responses, the tool-calling loop is controlled by the client's own code. That code must send the request, receive the function call, run the function, send the result back and decide when to stop.

The consequence is that things you never had to consider are now your responsibility. If the model keeps calling tools without stopping, after how many iterations do you cut it off?

How do you report a timeout in one of the client's functions back to the model, and what happens when two tools are called in parallel and one fails? These are questions about system reliability, not just API syntax.

The upside is that once the client writes this loop, it has a place to attach logging, measure latency at each step and block dangerous actions before they run. A good FDE presents this to the client as a benefit they gain, not a burden forced on them.

## Output changes shape, downstream systems misread it

The third risk is the hardest to spot, because nothing throws an error. Zoho warns customers that a response may now contain activity items generated during processing, such as file search and function call, not only the final answer.

Imagine an old piece of code that takes the first element of the output and writes it to the CRM as the bot's reply. On the new system, the first element may be a file search record. The CRM still receives data, no exception is raised, and staff start seeing strange text in customer histories.

The defence is to trace the output from the API to every place it is used: parsers, logs, dashboards, reporting systems. At each one, check whether the code filters by item type or assumes the output contains only messages. That list should exist before a single line of code is changed.

## What should developers do about this migration?

If your company has built chatbots or agents on Assistants for clients, sooner or later a migration ticket will probably land on someone in the team. Do not dodge it. It is good practice for exactly the kind of skill an FDE needs: stepping into an unfamiliar system, finding where data could be lost, and reaching agreement with the client before making changes.

When reading job descriptions, look for mentions of migration, legacy-system integration or tool calling; if they appear, experience with this migration is worth raising in an interview. On your CV, do not write "migrated to Responses API".

Write specifically how many conversations you inventoried, how much history you kept and which downstream failures you prevented, because that shows you think about consequences for the client, not just about the endpoint.

OpenAI gave exactly 12 months' notice, and any project still calling Assistants today has run out of waiting time. Whoever gets called in will need to know where the client's data lives, and that work comes before touching the code.

**Try this week:**

- In a codebase you maintain, find every call involving thread, run or assistant_id, and note which ones save messages to a separate database and which do not
- Write a minimal tool loop on the Responses API: send a request, run the function when a function call appears, send the result back, repeat until there is a final answer, with a cap on the number of iterations
- Take a real response that uses file search or function call, list every item type in the output, then check which types the downstream parser actually handles

## Sources

- [Assistants migration guide (OpenAI)](https://developers.openai.com/api/docs/assistants/migration)

- [Assistants API beta deprecation – August 26, 2026 sunset (OpenAI Developer Community, posted by edwinarbus)](https://community.openai.com/t/assistants-api-beta-deprecation-august-26-2026-sunset/1354666)

- [OpenAI sunsets the Assistants API: What it means for your Zoho SalesIQ integration](https://www.zoho.com/blog/salesiq/openai-assistance-api-migration-for-zoho-salesiq.html)