OpenAI Agent Builder is shutting down: how to migrate an agent without breaking it
OpenAI shuts down Agent Builder on 30 November 2026. There are two official paths: the Agents SDK if the agent lives in your application, and ChatGPT Workspace Agents if your staff use it inside ChatGPT. A code export exists, but it does not convert the workflow graph. So migration is mostly verification: capture real inputs before the shutdown and replay them on the new version.
7 min read
What exactly shuts down, and when
According to OpenAI's deprecations page, developers were notified on 3 June 2026 and Agent Builder is scheduled to shut down on 30 November 2026. ChatKit, per the same entry, remains available. The Evals platform closes at the same time: existing evals become read-only on 31 October and the dashboard and API shut down on 30 November. OpenAI names Promptfoo as the path for Evals.
It is the second such case within a year: the Assistants API was shut off on 26 August 2026, replaced by the Responses API and Conversations API. If your agent was built in Agent Builder and tested in Evals, both the agent and its tests have to move.
Agents SDK or Workspace Agents
The choice depends on where the agent runs today. If your website, bot or internal system calls it, you need the Agents SDK: code you deploy and maintain yourself. If staff use the agent inside ChatGPT, OpenAI offers Workspace Agents: the agent is described in natural language and shared with the team, but it requires a ChatGPT Business, Enterprise or Edu workspace.
| Question | Agents SDK | Workspace Agents |
|---|---|---|
| Where the agent runs | In your application and infrastructure | Inside your company's ChatGPT |
| Who maintains it | Your developers: code, deployment, permissions | The agent owner in ChatGPT |
| Strictly deterministic steps | Can be enforced in code | Per OpenAI's guide, may not carry over exactly |
| What to verify separately | Runtime, tools, authentication, permissions, deployment | Connected apps, authentication, publishing, permissions |
What the code export gives you, and what it does not
Agent Builder has an export: Code, then Agents SDK, then TypeScript or Python. OpenAI's guide states plainly that this does not convert the workflow graph. You get a starting point, not a guarantee of the same behaviour. Branches, conditions, tool calls and error handling need to be checked against the original canvas step by step.
What to collect before the move
The main mistake is to start by rewriting. First record what the agent does today, while the old version still runs. Especially results and scores from Evals: after 31 October they become read-only, after 30 November they are gone.
- Triggers: where requests come from and in what format.
- Tools and permissions: what the agent reads, what it changes and on whose behalf.
- Connected apps and how they authenticate.
- Rules and limits: which answers and actions are not allowed.
- 30 to 50 real inputs with the current version's outputs, including edge cases and failures.
- Where the agent is embedded: website, bot, internal portal, and who uses it.
A migration plan
Freeze changes in the old version. Export the code or rebuild the agent in Workspace Agents. Replay the collected inputs on the new version and compare answers and actions with the old ones. Go through the differences one by one: some will be improvements, some will be logic lost from the graph. Then route part of the traffic to the new version, keep a rollback path and only then switch over fully. Keep the input set as a regression suite: you will need it at the next model or platform change.
Should you stay with OpenAI at all
Migration is a good moment to separate what you own from what you rent. The process, tool contracts, data and authority rules are yours and move between platforms. The builder on top can be replaced. If the agent needs visual workflows and integrations, compare n8n and Dify; if it needs complex logic and tests in a repository, look at code frameworks. Our platform overview compares the options.