Agent Builder, Evals and saved prompts shut on 30 November. Here's what to pull out first

OpenAI is switching off three developer tools on 30 November: the Evals platform, Agent BuilderdefinitionOpenAI's drag-and-drop canvas for agent workflows. Someone publishes a workflow and gets an ID back. Your chat or app has been calling that ID ever since. and saved prompt objects behind the v1/prompts API. If your chat widget, your test suite or your production prompts live in any of them, they need a new home before that date. Evals already went read-only on 31 October, so the test half of this has started.

The failure here is quiet until it isn't. Nothing in your own code changes on 30 November. A website chat that gets its brains from an Agent Builder workflow loses that backend. An app that fetches its instructions by prompt ID loses the instructions. OpenAI's prompt migration guide doesn't say what those requests return after the date, so plan for them to fail.

The tests matter more than they look. For some teams, Evals is where they check that a model swap didn't make answers worse. OpenAI is also retiring several GPT-4o and GPT-4.1 snapshots, minis included, on 14 January, so plenty of teams have a model migration coming right after this one. They'll want their test set out of Evals and running somewhere else before that starts.

There's an access angle too, and it's easy to miss. Today the dashboard holds the prompt text, the workflow and the test data, and anyone with access to the project can change them. Once they move into your repo or a ChatGPT workspace, someone has to decide who can edit them and which API key or connected app each one runs under.

For engineers: a ChatKit session created against a hosted workflow sends workflow: {id} to the ChatKit sessions endpoint. OpenAI's ChatKit guide says you can keep using that hosted workflow during the transition window, and points new work and migrations at a ChatKit server you run yourself. Saved prompts show up as a prompt parameter on the Responses API with an ID, a version and variables. Search for both before you search for anything else.

Agent Builder is the hard one. The export hands you code, but it doesn't convert the workflow graph. Nobody promises every behaviour survives the trip either, so someone still walks each branch by hand.

Workspace agents have their own catch. OpenAI warns that a workflow built on a strict run of steps might not come across faithfully, so test the awkward paths first. Someone also has to set up the connected apps and permissions again in ChatGPT.

Prompt objects are the simplest move and the easiest to get slightly wrong. The prompt text goes into your code, the variables become ordinary function arguments, and the version history moves to git. OpenAI's guide adds one detail that saves money: keep the fixed instructions first and the parts that change per request last, because prompt caching only works on an exact matching prefix.

Don't expect an export button. The PromptfoodefinitionAn open-source test tool. You write the checks in a config file, then run them on a laptop or in CI. It's where OpenAI sends people leaving Evals. cookbook describes a manual rebuild instead: you recreate the prompts, the model settings, the test cases and the scoring rules in a Promptfoo config file, then run it. One developer on OpenAI's forum who has used Promptfoo said they couldn't point to anything they'd lost. Their team later dropped it for its own rubric-based evals, which is a reasonable choice if your checks are simple.

For most teams the choice is really about Agent Builder. Prompts go into code either way, and Evals goes to Promptfoo or your own harness. The agent is where you pick between owning code and handing the logic to ChatGPT.

The last row isn't on OpenAI's migration page. It came up on OpenAI's developer forum, where one practitioner suggested rolling a small wrapper over the Responses API, while calling the Agents SDKdefinitionOpenAI's code library for Python and TypeScript. Your developers drop it into their own app, and it handles the agent loop and handoffs. Hosting and keys are on you. a good replacement and the way to go otherwise. That matches what the SDK overview says about the trade: the SDK runs the agent loop and handoffs for you, and the raw Responses API leaves the whole integration to you.

The workspace agent route changes who owns the thing. It stops being an app your developers deploy and becomes something staff build and share in ChatGPT. That suits internal helpers. It's a poor fit for a customer-facing chat on your website, which is where ChatKit with your own server makes more sense.

Saving the Evals data is mostly a scripted job, so give it to a developer this week. The Evals API still lists your evals at GET /v1/evals, their runs at /v1/evals/{eval_id}/runs and each run's graded answers at /runs/{run_id}/output_items. You can filter those answers down to the failures, and they're usually the cases you'll want again. Page through everything. The output-items list, for one, returns 20 per page unless you ask for more.

Then search the code. The IDs in OpenAI's examples look like pmpt_123 and wf_123, so grep for those prefixes and for calls to chatkit/sessions, but check your config files, environment variables and low-code tools too. A workflow ID often sits in an environment variable on the server that creates ChatKit sessions.

OpenAI switched off the Assistants API in August, and now these three. The pattern is the same both times. Anything you build inside the vendor's dashboard is easy to start with and hard to take with you.

We pull the agents, prompts and tests out of OpenAI's dashboard and into code your team owns. Most of the work is an Agents SDK or ChatKit server build. Then the prompts get a reviewer, and the evals run in CI so nothing merges untested. See our OpenAI API page and the LLMOps and evaluation practice. If you need engineers for the cut-over, hire OpenAI developers, or start with a short assessment.