Moving off OpenAI Agent Builder before 30 November

OpenAI told developers on 3 June 2026 that it is closing Agent Builder, the Evals platform and reusable prompts. The closing date is four weeks away, and Evals has already gone read-only. If your company built agents in the Agent Builder canvas, the work to do this month is mostly export, testing and a decision about which agents deserve to survive.

We build agents on several of the tools below and we sell this kind of migration, so read the recommendations with that in mind.

What closes and when

These dates and lines come from OpenAI’s deprecations page, read on 2 November 2026. OpenAI writes dates in the American order, and each announcement is dated June 3, 2026.

Product	Date on OpenAI’s page	OpenAI’s wording
Evals platform	Oct 31, 2026	”Existing evals become read-only.”
Evals platform	Nov 30, 2026	”The Evals dashboard and API are scheduled to shut down.”
Agent Builder	Nov 30, 2026	”Agent Builder is scheduled to shut down.”
Reusable prompts	Nov 30, 2026	”The v1/prompts API and reusable prompt objects are scheduled to shut down.”

Reusable prompts are easy to miss, because the dependency sits in your code. If your code passes a prompt object with an ID and version to the Responses API, that call is on the same clock.

What stays

ChatKit stays. OpenAI’s deprecations page says it remains available, and it lists no shutdown date for it. But check how your ChatKit is connected, because there are two kinds. The ChatKit guide describes a hosted route that points at an Agent Builder workflow ID, and OpenAI now says to use that route only if you already have such a workflow. The guide describes no way to keep a hosted workflow running after the shutdown. The other route runs ChatKit on your own server, with OpenAI’s Python SDK for ChatKit recommended, and it can connect to any agent service, including one written with the Agents SDK.

So a chat window on your site can survive, but whatever answers behind it has to move if it is an Agent Builder workflow.

The Agents SDK also continues, and it is one of the two destinations OpenAI suggests.

What to export now

Do this before you make any other decision. An archive of an agent you later retire costs nothing, and after 30 November you should assume the dashboard copy is gone.

• Workflow code. In Agent Builder, open the workflow, select Code in the top navigation, choose Agents SDK, pick TypeScript or Python and copy the whole export. Commit it to a repository the same day. The steps are in OpenAI’s migration guide.
• The workflow’s design. OpenAI warns that the export does not convert the graph and does not promise identical behaviour, so take screenshots of the canvas and copy the instructions and tool settings for each node into the same repository. Record which published version production uses, since workflows are versioned and API calls can target an older one.
• Eval definitions. A reply from OpenAI support on its developer forum, dated 3 July 2026, describes two exports: a runnable Promptfoo configuration with prompts, models, test cases and assertions, and a JSONL file that holds results only. You want both. A forum user found the export under the (…) menu on an opened eval. We could not confirm from OpenAI’s pages that both exports still work now that evals are read-only, so try them today.
• Eval test cases by hand, if the export fails. OpenAI’s current cookbook entry on moving to Promptfoo describes recreating test data, prompts, models and scoring in a promptfooconfig.yaml file and does not depend on an export. It warns that previous runs do not carry over and that recreated graders need validating, especially ones where a model acts as the judge.
• Reusable prompts. Copy the text and variables of each prompt into your codebase. OpenAI’s prompt migration guide suggests one named function per prompt, with variables as typed arguments, and version history held in git. It does not explain how to bulk export prompts from the dashboard, so plan on copying them.
• What the agents did. Save whatever logs and traces you can reach for the past few months. Real inputs make the best test cases for the rebuilt version.

Where the agents can go

OpenAI suggests two destinations. The other three are independent choices, and they mean a rebuild, with the export used as a specification, because OpenAI’s export produces Agents SDK code and nothing else.

Destination	When it fits	Trade-off
OpenAI Agents SDK	You have engineers, the agent runs inside your own application, and you want the shortest path from the export. This is the default for most Agent Builder workflows.	You now host, deploy and monitor it yourself, and you must check tools, sign-in, permissions and runtime settings yourself. It has agents, handoffs, guardrails and tracing, and it supports other model providers.
ChatGPT workspace agents	The agent serves staff inside ChatGPT, and non-engineers should be able to change it. You need a Business, Enterprise or Edu workspace with permission to create agents.	OpenAI says workflows that depend on strict, repeatable logic may not move faithfully. Connected apps, sign-in, publishing and permissions all need a separate review.
n8n	You liked the visual canvas, the agent is mostly a sequence of steps across business systems, and your team can read a workflow but not a codebase. You can self-host it or use n8n Cloud. See our notes on self-hosted against cloud.	You rebuild by hand. The AI Agent node with tools and a Chat Trigger covers the common case. n8n’s Tools Agent docs say memory does not persist between sessions, so plan where conversation history will live. Complex agent logic gets harder to test on a canvas.
LangGraph	The agent runs for a long time, must resume after a failure, or stops for a person to approve a step, and you have engineers who want control of each stage. It is MIT licensed, with Python and JavaScript versions.	Its own docs describe it as low-level. You write more code, and it is more than a simple question-and-answer agent needs.
Claude Agent SDK	The agent’s work is reading files, running commands and editing files, and you want those tools, along with permissions, sessions and hooks, built in. It works in Python and TypeScript.	You are changing model provider as well as framework, so prompts and evals need retesting from the start. It runs the Claude Code binary in a process you operate, so it suits a server you control.

For evals, the replacement OpenAI points to is Promptfoo, an open-source command line tool that runs on your own machine. It works with whichever destination you pick, which is a good reason to move evals first.

If an agent is a fixed sequence with one model call in it, consider dropping the agent framework altogether and writing it as an ordinary workflow. Our guide to putting agents into production covers how to decide what an agent should be allowed to do.

A step-by-step move

The dates below are our suggestion for a team starting today. They leave nearly a week of margin, because the last week of a deadline is a bad time to find out a tool permission is missing.

1. By 6 November, list everything. Write down each workflow, its ID, its published version, what calls it (ChatKit, your API, a person testing it), who owns it and which prompts and evals belong to it. Search your code for workflow IDs, prompt_id and calls to the Evals API, because the dashboard only shows what was built there.
2. By 6 November, export everything using the list above, including agents you expect to retire.
3. By 10 November, decide keep, merge or retire for each one, using the questions in the next section.
4. By 10 November, choose one destination per surviving agent. Fewer is better. Two destinations are manageable for a small team, and five will leave you maintaining five sets of deployment and monitoring.
5. By 13 November, move the evals. Get a Promptfoo configuration running against the current Agent Builder version, using real inputs from your logs. This gives you a baseline while the old agent can still answer. Run with --no-cache, as the cookbook does, so cached outputs do not hide differences.
6. By 17 November, rebuild. Start with the agent that carries the most risk. Move prompts into code, re-create each tool with the least access it needs, and put API keys in your host’s secret store.
7. By 20 November, run both side by side. Send the same inputs to old and new, and compare against the evals. Read the differences yourself, particularly where the agent called a tool or took an action. OpenAI’s guide makes the same point for workspace agents: preview, test representative inputs, compare, and create the agent only once it passes.
8. By 24 November, cut over. Point ChatKit at your own server, or switch the API call. Add an alert for failures and for the agent going quiet, and name the person who receives it.
9. Before 30 November, remove the old references. Delete workflow IDs and prompt_id values from your code so that nothing fails on 1 December, and keep the archive in the repository.

Using the deadline to retire agents

Agent builders make agents cheap to start, so some end up with nobody looking after them. A forced move is a good moment to close them, because each one now has a visible cost: somebody has to rebuild and test it. Ask these questions of each agent and write the answer in the list from step 1.

• Who used it in the last 30 days? Use application logs and traces, and name people or systems. If the answer is only the person who built it, it is a candidate for retirement.
• What would stop if it were switched off on Monday? Ask the team it serves. Vague answers usually mean nothing would stop.
• What is the manual fallback, and how long does it take? If a person can do the task in a few minutes a week, the agent may not justify any maintenance.
• Who owns it now? An agent whose builder has left, with no one willing to take it on, should retire unless the business depends on it. If it does, finding an owner is the first job.
• Does it overlap with another agent? Three support agents with slightly different prompts can often become one agent with shared tools.
• Has anyone checked its answers lately? An agent with no evals and no complaints may be working, or it may be unused. The usage question tells you which.

If you are unsure, pause the agent for a week where that is safe and see who asks. Then retire what is left by removing it from wherever it is embedded, revoking its API keys and connected-app permissions, and keeping the export in your archive with a note saying why it closed. A short list of agents that each have an owner, a test set and an alert is a better result from this month than a like-for-like copy of everything.

What this does not settle

Vendors will keep changing products like this, and the export only helps once. Keeping prompts in git, evals in a tool you run yourself and agents in code or workflows you can move makes the next change a smaller job. It will not remove the work of retesting when you change a model or a framework.

If you want help sorting the list or doing the move, our AI agents service and Automation Audit cover it, and the pricing page shows what they cost. A team with an engineer and a small number of workflows can do this without us by following the steps above.

Sources

All pages were read on 2 November 2026.

• OpenAI, Deprecations
• OpenAI, Migrate from Agent Builder
• OpenAI, Agent Builder guide
• OpenAI, ChatKit guide
• OpenAI Cookbook, Moving from OpenAI Evals to Promptfoo
• OpenAI Developer Community, Evals deprecation thread, support reply of 3 July 2026
• OpenAI, Migrate from prompt objects
• OpenAI, Agents SDK documentation
• Promptfoo, Introduction
• n8n, Tools Agent and Hosting
• LangChain, LangGraph overview and LangGraph repository
• Anthropic, Agent SDK overview