Tips · Oct 21, 2026 · 12 min read
OpenAI Agent Builder Shutdown: How to Migrate Your Agents

Updated October 21, 2026. We checked every OpenAI date and recommendation in this post against OpenAI's deprecations page, its Agent Builder migration guide and its ChatKit docs on that day. The camelRun code is copied from the camelRun repository as it stood the same day, and each sample names the file it comes from.
OpenAI is shutting down Agent Builder on November 30, 2026. After that date, the visual canvas and the workflows built in it stop working. OpenAI announced the shutdown on June 3, 2026, together with two related products that close on the same day: Evals, which become read-only on October 31, and reusable prompts. ChatKit, the chat front end, stays.
OpenAI suggests two places to go next. The Agents SDK runs your workflow as code that you host. ChatGPT workspace agents rebuild it inside ChatGPT for your team. Whichever you choose, export each workflow's code and write down what the canvas holds before November 30, because the export lives inside Agent Builder.
This guide covers what to save, the options (OpenAI's own, plus camelRun, camelAI's hosted runtime for AI agents), how each Agent Builder node maps to code, and a short walkthrough of one agent on camelRun.
What shuts down, and when
| Product | Date | What happens | OpenAI's suggested path |
|---|---|---|---|
| Agent Builder | November 30, 2026 | The product shuts down | The Agents SDK, or ChatGPT workspace agents |
| Evals (dashboard and API) | Read-only on October 31, shut down on November 30, 2026 | Existing evals can't be changed, then the dashboard and API close | OpenAI's cookbook guide to moving evals to Promptfoo |
| Reusable prompts | November 30, 2026 | The v1/prompts API and stored prompt objects stop working | Keep each prompt in your own code |
| ChatKit | Not shutting down | Stays available | For a workflow OpenAI hosted, run ChatKit on your own server |
All three shutdowns were announced on June 3, 2026, according to the deprecations page and OpenAI's API changelog.
ChatKit needs a closer look. Its simplest setup passes an Agent Builder workflow ID and lets OpenAI run the workflow. OpenAI's ChatKit docs say existing setups can keep using that hosted workflow during the transition window. For anyone migrating before the shutdown, the docs point to running ChatKit on your own server with the ChatKit Python SDK, connected to an agent you run. If your site embeds ChatKit with a workflow ID, plan for that change too.
What to save from Agent Builder before November 30
Do this for every workflow you still use, even before you pick where it goes.
- Export the code. Open the workflow, select Code at the top, choose Agents SDK, then TypeScript or Python, and copy the whole export into your repository. Both of the paths in OpenAI's migration guide start from this export.
- Note the version your app uses. Write down each workflow's ID and the version your ChatKit setup or API calls pin, so you know which one was live.
- Copy each Agent node's settings. Save its instructions, its model configuration and its tools in a plain file. You can then check the export against what the canvas showed.
- List every tool. For each MCP node, write down the server, the tools it allows and how it signs in, or which OpenAI connector it uses. For each File search node, write down the vector store ID. For function tools, note which service answers them.
- Write down the guardrails and approvals. For each Guardrails node, note which checks it runs (such as PII or jailbreak checks) and what happens when one fails. For each Human approval node, note what the person is asked to approve.
- Write down the logic. Copy each If/else and While condition (they're CEL expressions), each Set state variable and each Transform. OpenAI's guide warns that control flow, triggers, tools and permissions may need to be rebuilt by hand.
- Save test cases. Run representative inputs in Preview, or pull them from your logs, and save the answers the workflow gives today. OpenAI's guide says to compare the new agent with the original workflow, and after November 30 the original can't run.
- Copy your evals. Save the datasets and grader settings. They become read-only on October 31 and are gone on November 30. OpenAI's suggested destination is Promptfoo.
- Copy reusable prompts. If your app calls the Responses API with a stored prompt, copy each prompt's text and variables into your code. OpenAI's prompt migration guide doesn't describe an export, so copy the current text by hand.
- Check the models. Some older OpenAI models have their own dates on the same deprecations page. For example, the dated GPT-5 and o3 snapshots shut down on December 11, 2026.
Where to move your agents
There are four realistic paths. OpenAI names the first two.
The OpenAI Agents SDK
The export is Agents SDK code, so this is the shortest move. OpenAI's guide has you copy the export into your application, install the matching SDK, test the workflow and deploy it. The Agents SDK is a library, so the agent loop runs in your own process. You host it, keep the conversation state, and own tool auth and permissions. If you used ChatKit's hosted option, you also run a ChatKit server.
This path fits when you're happy to run the agent on your own servers and want the code that stays closest to the export.
ChatGPT workspace agents
Workspace agents are agents your team builds and shares inside ChatGPT. To move a workflow, you create a workspace agent, paste the export into the chat and ask it to convert the workflow. Then you review its instructions, apps, tools and permissions, and preview it before you create it. You need a ChatGPT Business, Enterprise or Edu workspace with access to workspace agents. OpenAI warns that workflows that depend on strictly deterministic steps may not carry over faithfully.
This path fits agents that your own team used. It doesn't put an agent inside your product or on your website.
The OpenAI Agents API
OpenAI's Agent Builder guide doesn't mention it, but OpenAI also has a hosted option. The Agents API has been in public beta since September 10, 2026. OpenAI runs the agent loop (the Codex harness) and keeps durable sessions, and your app supplies the tools. It's code-first and runs OpenAI's models. Our post on camelRun vs the OpenAI Agents API covers it in detail.
This path fits when you want OpenAI to host the loop and you plan to stay on OpenAI models.
A hosted runtime that works with any model
camelRun is camelAI's hosted runtime for AI agents. Like the Agents API, it runs the loop for you and keeps each agent's history and files until you delete them. These are the differences that matter after Agent Builder:
- Any model. OpenAI models on your own key or through OpenRouter, plus Anthropic, Google, Amazon Bedrock and others, or any server that speaks OpenAI's or Anthropic's API. An agent keeps its history when you switch its model.
- Chat channels. Slack, Discord, Telegram, GitHub and signed webhooks can reach an agent directly, with one agent per conversation.
- Approvals that wait. A tool call can wait days for a person's approval, and nothing is billed while the agent waits.
- Open source. The runtime is AGPL and can be self-hosted with Docker and Postgres. The SDKs are MIT.
camelRun is code-first. You define agents with the TypeScript or Python SDK, or in an agent.yaml file that you deploy with the CLI. The console can set up an agent without code when its tools come from MCP servers, OpenAPI specs or built-in tools. There is no visual canvas and no drag-and-drop workflow. camelRun also has no vector search, no built-in guardrails and no handoffs, and the code its agents write runs JavaScript only. If the canvas is what you'd miss most, a visual workflow tool will suit you better.
For a side-by-side of the two hosted options, see camelRun as an OpenAI Agents API alternative.
How an Agent Builder workflow maps to code
Each part of the canvas has a place in code. The node names below come from OpenAI's node reference.
| In Agent Builder | On camelRun |
|---|---|
| Start node input | The message you pass to run(). Facts about the user go in the agent's subject and context, which the model can't change |
| Agent node instructions | instructions in the SDKs, or systemPrompt or systemPromptFile in agent.yaml |
| Agent node model | model, any id your account can use, from any provider |
| Tools on an Agent node | Functions in your TypeScript or Python code, a tool server over HTTPS, or built-ins such as web_search |
| MCP node | mcpServers. Remote HTTPS servers that take a token, headers or credentials your server hands out. OAuth sign-in isn't supported yet, and OpenAI's own connectors don't carry over |
| File search node | No equivalent. Agents have files and file tools, not vector search, so keep retrieval behind a tool of your own |
| Guardrails node | No built-in guardrails. Check input in your code before run(), and check run.text or run.output before you use it |
| Human approval node | An approval on the tool call itself, with needsApproval on a tool or an approval policy on an MCP or OpenAPI source |
| If/else | Structured output (output on a run, with zod, JSON Schema or pydantic), then a branch in your code. Or the delegate built-in, so the model hands the task to a specialist agent |
| While | A loop in your code. Each run already loops over tool calls until the model answers, within its run limits |
| Several Agent nodes in a row | A sequence of runs in your code, or a lead agent with delegate. camelRun has no handoffs |
| Transform | Structured output, or your code |
| Set state | Your code. The agent's history and files are kept for you |
| Publishing a version | camelrun deploy. A changed definition gets a new revision, and --apply moves live agents to it |
| Preview | camelrun run, or the console's Try it tab |
| Evaluate | No evals. Export traces with OpenTelemetry to a tool such as LangSmith or Langfuse |
| ChatKit with a workflow ID | A chat channel, or <AgentChat> with a server route in your own app |
The export is Agents SDK code, and camelRun's migration guide maps the Agents SDK to camelRun concept by concept. Here is the smallest example, from docs/guides/migrating.md in the camelRun repository. First, an agent in the Agents SDK:
from agents import Agent, Runner, SQLiteSession, function_tool
@function_tool
def lookup_order(order_id: str) -> dict:
"""Look up an order by id."""
return orders.get(order_id)
agent = Agent(name="Support", instructions="You help with orders.", tools=[lookup_order])
result = await Runner.run(agent, "Where is order 42?", session=SQLiteSession("user-123"))
print(result.final_output)
The same agent on camelRun:
from camelai_run import Agents, tool
@tool
def lookup_order(order_id: str) -> dict:
"""Look up an order by id."""
return orders.get(order_id)
async with Agents() as agents: # reads CAMELAI_API_KEY
agent = await agents.upsert("user-123", instructions="You help with orders.", tools=[lookup_order])
run = await agent.run("Where is order 42?")
print(run.text)
The key ("user-123") takes the place of the SDK's session. The same key is the same agent, with its history, from any process, and nothing is stored on your side. Before you port, know that tools passed this way are served by the one process that holds the agent. If several workers run the same agent, serve the tools over HTTPS instead, as the migration guide shows.
Walkthrough: one Agent Builder agent on camelRun
Say your workflow was a support agent. It had one Agent node with instructions, an MCP server for your app, web search, and a Human approval before anything risky. Here is that agent as an agent.yaml file, deployed with the CLI.
Install the CLI and sign in
The CLI needs Node 22 or later and an API key (the quickstart shows where to get one). From packages/cli/README.md:
npm install -g @camelai/camelrun
camelrun login # an API key from the console's API tokens page
camelrun init support # writes agent.yaml
camelrun deploy # the definition, and the agents it lists
camelrun run support "Which tickets look urgent?"
camelrun run takes the place of Preview. The console's Try it tab does the same in the browser.
Move the Agent node into agent.yaml
The manifest keeps the agent's configuration in your repository. This one is from docs/reference/cli.md:
key: support # the same key is the same definition
name: Support
model: anthropic/claude-sonnet-5-5
systemPromptFile: prompts/support.md
builtins: [web_search, ask_user]
mcpServers:
- name: app
url: https://app.example.com/mcp
auth: { type: bearer, token: "${APP_MCP_TOKEN}" }
openApi:
- name: billing
specFile: openapi.yaml
auth: { type: runtime }
agents: # keyed agents made from it on deploy
- key: support-main
- key: support-eu
systemPromptAppend: Answer customers in the EU region.
Here is how it lines up with the canvas:
systemPromptFilepoints to a Markdown file. Paste your Agent node's instructions intoprompts/support.md.modeltakes any model id your account can use, andcamelrun models --availablelists them. To stay on OpenAI's models, add your OpenAI key under Models & keys in the console, or use them through OpenRouter.builtinsreplaces hosted tools.web_searchsearches the web, andask_userlets the model ask the person multiple-choice questions.mcpServersreplaces an MCP node.${APP_MCP_TOKEN}is read from your environment when you deploy, so the token stays out of the file. The server has to be reachable over public HTTPS.openApiturns each operation in an OpenAPI spec into a tool, which covers function tools that called your own API.auth: { type: runtime }sends a signed token naming who each call is for.agentslists keyed agents to make on deploy. Each key is one agent with its own history until you delete it. An app that gives every user an agent of their own makes them from code instead, from the same definition.
Deploying again makes a new revision only when the file changed. camelrun deploy --apply moves live agents to the new revision between their turns, and they keep their history. That's the closest thing to publishing a new version.
Add the approvals
In Agent Builder, a Human approval node was a step in the graph. On camelRun, an approval belongs to a tool call. The person sees the real call, with its tool and arguments. An approved call runs with exactly those arguments, and a declined call never runs.
You set approvals on a tool source. This definition, from docs/guides/human-input.md, asks before every delete_repo call, says who may approve, and lets a request wait one day:
{"name": "Ops", "builtins": ["ask_user"], "humanInput": {"expiresInSeconds": 86400, "approvers": ["slack:U0123"]},
"mcpServers": [{"name": "github", "url": "…", "approval": {"tools": {"delete_repo": "always"}}}]}
The same fields work in agent.yaml, since everything in it except key, agents and systemPromptFile is sent as the definition. A source's default can be never, always or destructive. Destructive means MCP tools marked as destructive and OpenAPI operations other than GET, HEAD and OPTIONS. For a tool in your own code, set needsApproval: true on the tool.
When a call needs approval, the run stops with input_required, the agent goes to sleep, and nothing is billed while it waits. Your app can answer from any process, minutes or days later. From the same file:
let run = await agent.run("Delete the staging database", { user: "alice" });
while (run.status === "input_required") {
const input = run.inputs[0];
console.log(input.kind, input.message); // "approval", "Allow db__drop to run?"
run = await input.answer(true, { from: "alice" }); // resolves with the resumed run
}
console.log(run.text);
A request waits 7 days by default and at most 30. In Slack, Discord or Telegram, the agent's reply asks for the approval as text, and a person who is allowed to answer replies "approve" or "deny".
Replace ChatKit
There are two ways to put the agent in front of people.
- A chat channel. On the console's Channels page, connect Slack, Discord, Telegram, GitHub or a webhook to the definition. Each conversation gets its own agent, such as a Slack thread or a Telegram chat. Channels are set up in the console or with the REST API, not the CLI. Channel agents take their tools from the definition, so tools that run in your own code have to be served over HTTPS.
- Chat in your own app. A server route (
createAgentHandler) and a React component (<AgentChat>) put a streaming chat with each user's agent in your app, and your API key stays on your server. Vue, Svelte and Solid get headless bindings. There's no hosted embed script. The chat app docs walk through it.
What it costs
camelRun is prepaid. You pay $0.01 for each hour an agent spends in a run, and $0.10 per GB-month of storage. Tokens cost nothing extra on your own provider keys, and the provider's price with no markup on ours. Idle and sleeping agents cost only storage. There's no subscription, no seats and no per-agent fee. The pricing docs have the details.
Summary
- OpenAI shuts down Agent Builder, Evals and reusable prompts on November 30, 2026. Evals become read-only on October 31. ChatKit stays, and OpenAI points anyone migrating to a ChatKit server of their own.
- Before the date, export each workflow's code (Code, then Agents SDK) and write down its instructions, tools, guardrails, approvals, logic and test cases.
- OpenAI's suggested paths are the Agents SDK, which you host, and ChatGPT workspace agents, which need a Business, Enterprise or Edu workspace. The Agents API, in public beta, is OpenAI's hosted option.
- camelRun hosts the loop with any model, keeps each agent's history and files, waits on approvals, and connects to Slack, Discord, Telegram, GitHub and webhooks. It's code-first, with no visual canvas.
- camelRun's migration guide maps Agents SDK code to camelRun, and the camelRun page has the rest.