Agent Builder’s scheduled November 30, 2026 shutdown is close enough to turn a vague migration plan into a practical question: what do you need to preserve so you can tell whether a replacement still does the job?
There is one deadline already behind us. OpenAI’s Evals platform became read-only for existing users on October 31. The docs still list November 30 as the scheduled shutdown date for both Evals and Agent Builder. That does not mean every OpenAI agent product is disappearing: the Agent Builder guide says ChatKit remains available. It does mean a visual workflow and its hosted evaluation surface are not a reliable long-term filing cabinet.
The tempting move is to export code and call it progress. Exporting is useful, but it is not the same thing as preserving behavior. OpenAI’s migration guide is unusually clear here: an export does not convert the workflow graph or guarantee that every behavior transfers unchanged. A code file can be a reference. It cannot, by itself, prove that a rebuilt workflow takes the same route, reaches the same tools, or handles a familiar input as intended.
That is why the first migration artifact should be a small recovery ledger, not a heroic rewrite. The ledger records the observable contract, the export, the surrounding pieces that require separate rebuilding, and the evidence you will use to judge the result. It is deliberately boring. Boring is underrated when a product retirement gives every unfinished task a dramatic soundtrack.
First, separate the products and the problem
Agent Builder is the visual canvas where a workflow can combine agents, tools, and control flow. Its documentation describes deploying a workflow through ChatKit or downloading Agents SDK code to run it elsewhere. Evals are for checking whether model outputs meet expectations you specify. They are related in a workflow, but they solve different problems: one describes and runs the system; the other gives you a way to test whether its outputs still meet a stated bar.
The migration guide offers two broad paths for an exported workflow: continue with the Agents SDK in an application, or use the export as input when recreating a workspace agent. The workspace-agent route requires a ChatGPT Business, Enterprise, or Edu workspace, access to workspace agents, and permission to create agents. The paths are not interchangeable access entitlements. Neither route removes the need for review: the guide calls out control flow, triggers, tools, permissions, authentication, connected apps, and publishing configuration as areas that may need manual attention.
So start by preserving what you can inspect without copying secrets, private prompts, customer records, or production payloads.
Copy this: Workflow & Evidence Recovery Ledger
Put this table in a Markdown file or issue tracker. Use references and labels, not credentials or sensitive data.
| Ledger row | Capture now | Acceptance question |
|---|---|---|
| Workflow contract | Workflow name or ID reference; trigger; intended input and output; route or handoff; one non-sensitive example | Can another person state what the workflow is meant to do? |
| Export baseline | Export date; TypeScript or Python choice; repository or reference location; version note | Do we have a readable reference, rather than a promise of equivalent behavior? |
| External edges | Tool or app names; permission-scope label; auth owner or contact; deployment or ChatKit relationship — no secrets | Which connections require a separate rebuild and review? |
| Evaluation evidence | Representative non-sensitive cases; expected properties or outcomes; grader or rubric wording; one known failure case | Can the replacement be judged against the old expectations? |
| Cutover proof | Replacement runtime; test date; same-case results; differences; reviewer decision; rollback or hold note | Did observed behavior meet the stated contract before traffic changes? |
1. Write the contract before you edit it
For each workflow, describe the input it receives, the output it is supposed to produce, and the handoff or route that matters. Add a safe example only if it helps make the behavior unambiguous. This is not a specification contest. A few plain sentences are more useful than a diagram nobody can test.
The key is that the contract describes outcomes a reviewer can observe. “Uses the new agent stack” is not an outcome. “Routes this category of request to the correct next step and returns a response with these properties” is closer to one.
2. Treat the export as a baseline, not a verdict
Export the workflow while the documented transition window is still open, then record where the reference lives and which language you chose. Keep the export alongside its context: a date, a version note, and the contract it is meant to support.
This framing prevents a common category error. An export may help rebuild an implementation, but it does not automatically recreate the graph or validate runtime behavior. The migration guide specifically says to validate application configuration and behavior before deployment. Save the file; do not mistake saving the file for testing the system.
3. Map the edges that code cannot safely carry
Tools, connection permissions, authentication, and publishing settings deserve their own row because they need separate review. Record a tool name, an access-scope label, and the person or team responsible for reconfiguring it. Leave out keys, tokens, and copied credentials.
This matters even when the replacement looks familiar. A workflow can be logically sound while a missing permission, disconnected app, or changed trigger quietly changes what it can do. If the replacement will use connected tools or private data, follow the same safety practices you applied to the original workflow.
4. Preserve test cases and the definition of “good enough”
OpenAI describes the basic eval loop as defining the task, running test inputs, then analyzing results and iterating. Preserve a small, representative set of non-sensitive cases along with the expected properties and rubric. Include at least one case that the old workflow handled poorly, if you have a safe example; migration is a chance to retain known limits rather than rediscover them later.
You do not need to promise identical scores or feature parity. The useful comparison is narrower: run the same cases against the replacement, note the differences, and decide whether those differences meet the contract you wrote in row one.
5. Make cutover proof a decision, not a folder
Before changing traffic, record the replacement runtime, test date, outcomes for the same cases, material differences, and the reviewer’s decision. If the evidence is incomplete, a hold note is a valid result. It is better than a confident-looking export with no way to explain what changed.
The practical rule is simple: an export is a reference artifact; comparable behavior is the acceptance test. With Agent Builder and Evals on a documented retirement timeline, that distinction gives a migration team something portable to carry forward: not just code, but the evidence needed to evaluate the next version.
