OpenAI Agent Builder shuts down Nov 30: what to do

If your business built a workflow in OpenAI's Agent Builder, it has an end date. OpenAI announced the deprecation on June 3, 2026, and Agent Builder is scheduled to shut down on November 30, 2026. ChatKit, the chat widget many teams used to put those workflows on a website, stays available. The visual canvas does not.

This guide is for owners and operations leads who had someone set up an Agent Builder workflow (a support helper, a lead intake bot, an internal question answerer) and now need to decide where it goes. We read OpenAI's deprecations page and the Migrate from Agent Builder guide on October 25, 2026. We also checked OpenAI's workspace agent trigger docs the same day. Everything below about OpenAI's tools comes from those pages.

• June 3, 2026. Agent Builder deprecation announced.
• October 31, 2026. Existing evals in OpenAI's Evals platform become read-only. If you used Evals to test your workflow, export or copy those test cases this week.
• November 30, 2026. Agent Builder shuts down. The Evals dashboard and API, and reusable prompt objects (the `v1/prompts` API), are also scheduled to shut down that day.

If your workflow also leans on saved prompts or evals, you have three things to move before the deadline.

There is one export. In Agent Builder, open the workflow, choose Code in the top navigation, pick Agents SDK, then pick TypeScript or Python and copy everything. OpenAI is clear about what that export is and is not: it "does not convert your workflow graph or guarantee that every behavior transfers unchanged." You get code that describes your agents, tools and logic. You do not get a running app.

From there, OpenAI offers two paths.

1. 1Keep it as code with the Agents SDK. You paste the export into an application, install the matching SDK, wire up tools and logins, and host it yourself. This keeps the most control and is the natural home for a workflow that sits inside your product or website.
2. 2Rebuild it as a ChatGPT workspace agent. If you have a ChatGPT Business, Enterprise or Edu workspace with permission to create agents, you paste the export into the agent builder in ChatGPT and ask it to convert the workflow. You then review the instructions, reconnect apps and permissions, preview with real inputs, and only then create the agent.

OpenAI lists the limits plainly. Workflows with "strong determinism at their core" may not move faithfully to a workspace agent. Connected apps, sign-in, publishing and permissions all need a separate review in ChatGPT. And an Agents SDK version needs you to check your own hosting, tools and access before it goes live.

Many Agent Builder workflows were not really agents. They were a fixed set of steps with one or two AI calls in the middle: read a form, classify it, look something up, send a reply. If that sounds like yours, a workflow tool such as n8n, Make or Zapier may be a better home than either OpenAI option. You keep a visual editor, the steps run the same way every time, and the AI step becomes one node you can swap later.

Independent converters that turn the Agents SDK export into an n8n workflow have appeared since the announcement. Treat their output as a first draft. OpenAI's guide warns that some workflow behavior may need to be recreated by hand, and any apps and logins the workflow used have to be set up again with the workflow tool's own integrations.

If you are not sure which side of that line your workflow sits on, our post on AI agents vs automations walks through the difference.

Answer these for each workflow:

• Does it run inside your website or app? Use the Agents SDK, or ChatKit plus the SDK if you already use ChatKit on your site.
• Is it a helper your team chats with inside ChatGPT? A workspace agent is the shortest path, if you are on a plan that includes them.
• Is it the same steps every time, triggered by a form, email or new record? Move it to a workflow tool. Determinism is what those tools are built for.
• Does it need an answer back right away, in your own system? Build it on the Agents SDK. OpenAI's workspace agent trigger docs say a trigger is queued and answered with "202 Accepted", and you check the run's status separately, so you do not get the finished answer back in the same call.
• Does nobody use it anymore? Let it shut down. Write down what it did in case you want it back.

A forced move is a good time to fix what never quite worked. When we migrate a workflow like this, the work usually looks like this:

• Inventory. List every Agent Builder workflow, who owns it, what triggers it, what tools and logins it uses, and whether ChatKit, saved prompts or evals depend on it.
• Export and freeze. Export each workflow's Agents SDK code now and store it with your other business documents, so you are not racing the shutdown.
• Collect real test cases. Pull 20 to 50 real past inputs and the answers you wanted. These become your check that the new version behaves the same. Our post on testing AI agents before production covers how we build that set.
• Rebuild on the right home. Agents SDK for product and website agents, a workspace agent for internal chat helpers, a workflow tool for fixed steps.
• Tighten permissions. Give the new version only the access it needs, and put a person in front of anything that sends money, changes records in bulk, or emails a customer.
• Run both side by side. Send the same inputs to the old and new versions for a few days before you switch, while the old one still exists.

Typical workflows we would rebuild this way include a website lead qualifier that writes to your CRM, a support triage step that drafts replies for a person to approve, and an internal policy question answerer that reads from a shared drive.

• Hidden dependencies. A workflow can look simple on the canvas and still rely on uploaded files, a saved prompt, or an app connection set up by someone who has left. Find those before November 30.
• Behavior drift. The export does not promise identical behavior. Compare outputs on your test set, especially edge cases and refusals.
• Logins and secrets. Exports do not carry your credentials. Plan who creates the new keys and where they live.
• Model changes. The same deprecations page lists GPT-4o and GPT-4.1 models leaving the API on January 14, 2027. If your workflow uses one of those, pick its replacement during this move instead of doing a second migration later.

If a workflow handled a few requests a week and a person can do the job in minutes, the cheapest fix may be to retire it and use a shared inbox rule or a simple form. Moving an agent costs time, and keeping it running has an ongoing cost too. Our post on automation maintenance costs explains what that upkeep looks like.

It is also not worth rebuilding something nobody trusted. If your team double-checked every answer anyway, fix the process first, then decide whether it needs AI at all.

Today, open Agent Builder and export every workflow's Agents SDK code. Then write one line per workflow: what it does, who uses it, and how often. That list is enough to decide which ones to move, rebuild or retire.

If you want help, our free automation audit looks at what you have and tells you where each workflow should live, or whether it should exist at all. For the rebuild itself, see what our workflow automation and AI agent development projects include.