OpenAI Closes Evals and Agent Builder Nov 30: What to Do

Most of the attention on OpenAI's deprecations this fall goes to the models. A quieter set of shutdowns affects the tooling around the models, and it may hurt more because there is no one-line replacement.

According to OpenAI's deprecations page, announced in early June 2026, three things end on November 30, 2026:

• The Evals platform, both the dashboard and the API. Existing evals become read-only on October 31, so you lose the ability to run or edit them a month before the final shutdown.
• Agent Builder, the visual workflow tool. OpenAI points to the Agents SDK or ChatGPT Workspace Agents as the replacement.
• Reusable prompts, meaning the v1/prompts API and prompt objects. No replacement is listed. OpenAI's guidance is to move the prompt content into your application code.

Separately, the Assistants API already shut down on August 26, 2026, with the Responses and Conversations APIs as its successors. If you are reading this and still have Assistants code, you have a bigger problem than this article covers, and you should handle it first.

The common thread: OpenAI is pulling back from hosting your workflow logic, your test suites and your prompt library, and pushing you toward running those yourself with its SDK. That is a defensible product decision. It is also a reminder of the real cost of building your process inside a vendor's dashboard.

Before you plan a migration, find out whether you are affected. Some teams clicked around in Agent Builder during a hackathon and forgot. Others run their whole quality process on hosted evals.

Three quick checks:

1. Prompts. Search your codebase for calls that reference a stored prompt by id instead of passing instructions inline. In the Responses API this shows up as a prompt object with an id and version. If you find any, those requests will fail after the shutdown.
2. Evals. Open the Evals section of the OpenAI dashboard and look at what exists and when it last ran. Ask whoever owns quality for your AI features. If they say "we run evals before each release," ask where.
3. Agent Builder. Look for workflows built in the visual editor and anything embedding them, such as a ChatKit widget or an exported workflow. Ask your product and ops people too. Non-engineers like Agent Builder because they can use it without a deploy.

If all three come back empty, you are done. Send a note to your team saying so, so nobody builds a new dependency on any of them this month.

This is the easiest migration and the one with the most upside. Hosted prompts were convenient, and they also hid your most important product logic outside version control. No code review, no history your team can read, no tests, and a change in the dashboard could alter production behavior in seconds.

The move:

1. Export every prompt and every version you use. Copy the text, the variables and the model settings into files today. Do not wait for November. Assume the API gets harder to use as the date approaches.
2. Store them in the repo. One file per prompt, with the variables clearly marked. Plain text or Markdown files with a small loader is enough. Use your language's template syntax for variables.
3. Pin the model and settings next to the prompt. A prompt and its model are one unit. A prompt tuned for one model can behave differently on another, as the GPT-4 and o1 shutdowns this month show.
4. Add a test per prompt. Even five example inputs with expected properties beats nothing.
5. Cut over behind a flag. Compare the output of the inline prompt against the stored one on live traffic before you remove the stored reference.

If your non-engineers edit prompts (a support lead tweaking tone, say), you do not have to take that away from them. You do need somewhere for them to edit that is not OpenAI's soon-to-be-gone dashboard. Options range from a plain pull request flow that a technical teammate helps with, to a dedicated prompt tool. Our write-up on building a prompt management system covers how to give non-engineers safe access with versions and rollback.

The date to remember here is October 31, not November 30. After that, existing evals can be viewed but not edited or run. If your release process depends on hosted evals, you have 18 days from today to have a replacement running.

What to pull out of the platform:

• The datasets. The test inputs and expected outputs are the valuable part. Export every one.
• The graders. Whatever criteria you scored on: string match, model-graded rubrics, custom code. Copy the rubric text exactly.
• The results history. Past runs let you set a baseline for the new tool. Download what you can.

OpenAI lists a Promptfoo migration path in its notice. Promptfoo is an open-source eval runner that works from config files in your repo, runs from the command line and slots into CI. For a small team that wants the shortest path, it is a good default. Datasets live in files, graders are config, and a run is one command.

It is not the only option. Hosted tools such as Braintrust and Langfuse give you a UI, shared experiment history and production tracing alongside evals. We compared them in Braintrust vs Langfuse vs PromptLayer. My rule of thumb: if you have one or two engineers and a handful of AI features, start with Promptfoo in the repo. If product managers, support leads or a data team need to look at results and label examples, pay for a hosted tool.

Agent Builder workflows are the hardest of the three to move, because the workflow lives in the tool. There is no exporter that gives you clean production code, so plan for a rebuild.

OpenAI names two destinations, and they are for different people.

The Agents SDK

This is the path for anything customer-facing or anything that needs to run inside your product. You define agents, tools, handoffs and guardrails in code. You get version control, tests, your own logging and deployment on your own infrastructure. The cost is engineering time. A simple three-step workflow can be rebuilt in a day or two. A multi-agent flow with approvals and external tool calls is closer to a week once you add tests.

ChatGPT Workspace Agents

This is the path for internal automations that your team uses inside ChatGPT, such as a research assistant or a document-drafting helper. It keeps the low-code feel. The tradeoff is that the agent lives inside OpenAI's product and follows its rules, so it does not fit if you need the workflow to run inside your app.

Or use a different framework

You are rebuilding anyway, so ask whether OpenAI's SDK is the right base. Anthropic, Google and the open-source frameworks all offer agent tooling. We compared the main options in Claude Agent SDK vs OpenAI Agents SDK. If your agent logic is mostly prompts and tool calls, the portability between SDKs is better than it was a year ago. Pick based on which models perform best on your task, not on which logo you started with.

Whatever you choose, write down the current workflow before you rebuild it. Open the Agent Builder canvas, screenshot each node and list inputs, outputs, tools and branching conditions. Then write a handful of end-to-end test cases from real runs. The rebuilt version has to pass them.

Founders ask me for a number, so here are honest ranges for a team that has a handful of AI features and nothing exotic.

• Moving prompts into code: half a day to two days of engineering, depending on how many prompts and how many versions you rely on. The testing is most of the time.
• Replacing hosted evals: two to five days to stand up a repo-based runner, port datasets and confirm the graders score the way the old ones did. A hosted tool adds a subscription, typically tens to a few hundred dollars a month at small-team scale, and saves setup time.
• Rebuilding Agent Builder workflows: one to two days for a simple linear flow, up to a couple of weeks for a branching, multi-tool agent with approvals and good logging.

Those are engineering days at market rates, so the money is real but modest next to what a failed customer-facing workflow costs you. The expensive mistakes are not technical. They are these:

1. Exporting only the final version. Prompts change over months for reasons nobody wrote down. Export the history too, so you can see why a sentence in a prompt exists before you delete it.
2. Treating the grader as neutral. A model-graded rubric moved to a different grader model can shift every score. Rerun a past set and check that old and new graders agree before you trust any new number.
3. Forgetting the owner. If the person who built the Agent Builder flow was a product manager or an ops lead, they are the only one who knows what it does on the odd path. Sit them down with the rebuild.
4. Rebuilding exactly what you had. A migration is a cheap moment to cut the dead branches. Look at which nodes fired in the last 90 days and skip the ones that never did.
5. Waiting for a replacement announcement. OpenAI listed no direct successor for reusable prompts. If you wait for one, you will lose the exports window.

The upside is real, too. Teams that finish this move usually end up with prompts under code review, tests that run on every pull request and a workflow they can read in a diff. That is a better position than a dashboard gave them.

From today to November 30 is about seven weeks, with a hard checkpoint on October 31. Here is a schedule that works for a small team.

1. This week: run the three checks, export prompts, datasets, graders and workflow screenshots, and commit them to a repo even if they are messy. The exports are insurance.
2. By October 24: choose the eval runner and stand up a first run on your exported datasets. Compare scores with the last hosted run to confirm the new grader agrees with the old one.
3. By October 31: eval process fully off the OpenAI platform. Prompts moved into code behind a flag.
4. November 1 to 15: rebuild Agent Builder workflows. Test against recorded cases. Run old and new side by side on internal traffic.
5. November 16 to 25: cut over customer traffic, then remove the stored prompt references and the Agent Builder embeds.
6. November 26 to 30: buffer. Something will have been missed. A cron job, a staging environment, a teammate's side project.

One caution on timing. The October 23 model shutdowns and these tool shutdowns overlap, and many of the same people are doing both. If your team is small, do the models first, because a retired model breaks production on a fixed date. The tooling migration can slip a few days without customers noticing, as long as you have exported everything.

Every one of these shutdowns has the same shape. A vendor offers a convenient hosted layer. A team builds process on it. The vendor decides the layer is not the business it wants and gives six months of notice. The team scrambles.

You will not avoid vendor tools. They are a good way to move fast, and I would not tell a founder with six weeks of runway to build their own eval harness. You can still put a rule in place: anything that encodes how your product behaves should be exportable in plain files, and ideally live in your repo. Prompts, test cases, grader rubrics and workflow definitions fit that rule. Dashboards for looking at results do not need to.

Ask three questions before adopting any hosted AI tool:

• Can I export everything I put in, in a format another tool could read?
• If this vanished in six months, how many days of work is the replacement?
• Is the vendor's core business this tool, or is it a side feature of something bigger?

The third question is the cheapest warning sign. A tool that is a vendor's whole company gets support and care. A feature bolted on beside the main product gets cut when priorities move.

If you want a second pair of hands, we help founders pull this kind of logic out of vendor dashboards and into code they own, with tests that keep working when the next provider changes course. Book a free strategy call and we will look at what you have built on OpenAI's tooling and tell you honestly how big the move is.