OpenAI Agent Builder Shuts Down: Where to Migrate

The headlines said “AgentKit is dead,” which is wrong and caused a round of unnecessary panic. Two products are being retired, not the whole toolkit.

That Prompt Objects row is the one people are going to get burned on. It's tempting, mid-migration, to lift your prompts out of the canvas and into dashboard Prompt Objects because it feels like progress. Those die on the same day. You'd be migrating twice for no reason.

Separate the two decisions. Getting your work out of a product that has a shutdown date is urgent. Choosing the perfect new home is not. Do the first one now.

In Agent Builder: open the workflow, click Code in the top nav, pick Agents SDK, choose TypeScript or Python, copy it out. Commit it. Do that for every workflow you have, including the abandoned experiments — a half-finished prototype you can read in six months is worth more than a memory of one.

Then read OpenAI's own migration guide and note what it admits: the export does not convert the workflow graph, and it does not guarantee that every behavior transfers unchanged. You get agent definitions, tool signatures and prompt text. You do not get your branching, your guardrail placement or your error paths. Those you re-implement and re-test by hand.

Evals deserves its own calendar entry. October 31 is when existing evals go read-only, and read-only still lets you pull data out. If you have a graded test set that took weeks to curate, script the export now. Rebuilding a labeled dataset from scratch costs vastly more than an afternoon of API calls. I went through why that test set is the asset — not the workflow — in the piece on evaluating n8n AI agents.

OpenAI names two. There's a third that a lot of the affected workflows actually want, and it's not from OpenAI.

If the thing you built reasons, calls tools, evaluates results and loops, the Agents SDK is the shortest path because the export targets it directly. You keep the OpenAI models, you keep the tool-calling semantics, and you trade a canvas for a repo — which gives you diffs, code review and rollback, none of which the canvas ever offered.

The cost is real though: you now own hosting. Several people in the deprecation thread went straight to Lambda, Workers or similar, and immediately hit the thing nobody plans for — cold starts. Reported numbers ranged from roughly 2.5–3.4 seconds on Lambda to 15–30 seconds on other platforms. A 30-second cold start in front of a chat widget is not a latency problem, it's a broken product. Budget for warm instances.

If you're rewriting into code anyway, this is also the cheapest moment you will ever get to reconsider the framework — I compared the shape of these SDKs in Claude Agent SDK vs LangGraph. You are already paying the port cost. Pay it once, in the direction you actually want.

Be honest about this one. A meaningful share of Agent Builder workflows are a system prompt, one or two tools and a chat box. That does not need a repo, a deploy pipeline or an on-call rotation. Workspace Agents handles it in natural language, and the ops burden drops to zero.

The tell: if nothing in the workflow runs unless a human types something, this is probably your answer. You're still inside OpenAI's walls, and the last six months should tell you what that's worth — but for an internal assistant that ten people use, that's an acceptable trade.

Here's the category OpenAI won't point you at, and it's the one I see most often in client accounts: a workflow that fires on a webhook or a schedule, pulls from a CRM, asks a model to make one judgment call, and writes the result somewhere. That is event-driven automation. It was only living in Agent Builder because the canvas was pleasant.

n8n gives you back the visual canvas, adds hundreds of real integrations you'd otherwise hand-write, and — the part that matters given the last six months — it runs on your own box, so no vendor gets to schedule its death. It's also model-agnostic: Claude, Gemini, a local model, or the same OpenAI endpoints you're on now, swapped in a dropdown rather than a rewrite.

It is not free of tradeoffs. You maintain it, you upgrade it, and you own the incidents. I laid out that math in n8n Cloud vs self-hosted, and the version-control gap in n8n version control without Enterprise. Going in with eyes open beats discovering it during an outage.

“ChatKit is not deprecated” is technically true and practically misleading. ChatKit shipped with two integration modes: a recommended one where OpenAI hosted the backend and your Agent Builder workflow drove it, and an advanced one where you run your own server. The recommended path was welded to Agent Builder. It goes when Agent Builder goes.

So if you shipped a ChatKit widget the easy way, the component in your front end survives and the thing powering it doesn't. Nobody sent you an email that said “you now operate a backend,” but that is the change. Scope it that way and the cold-start numbers above stop being trivia.

The best comment in the whole deprecation thread wasn't a complaint, it was an architecture note: the backend is the same code for every client, with the per-client parts — instructions, tools, knowledge — stored as data. You build the loop once, not once per customer.

That's the whole lesson of this shutdown. Anything you drew in a vendor's canvas exists at that vendor's pleasure. Anything sitting in your repo or your Postgres is portable by construction. Concretely:

Prompts live in version control — a file, a table, a config service you own. Never a vendor dashboard.

Tool definitions live next to the tools — schemas belong in the codebase that implements them.

The orchestration loop is yours — a canvas is an editing surface, not a runtime you can depend on.

Eval datasets live in your storage — the graded examples are the moat; the dashboard rendering them is a commodity.

Follow that and this stops being a migration and becomes a swapped adapter. Ignore it and you'll be reading this same post about a different product in eighteen months.

This week: export every workflow to Agents SDK code and commit it. No decisions required, no downside, and it removes the deadline pressure from everything that follows.

Before October 31:export Evals datasets and run history. This one has the earlier deadline and it's the piece that's genuinely expensive to rebuild.

By mid-October: sort each workflow into agent, prompted assistant, or event-driven automation, and route it to the SDK, Workspace Agents, or n8n accordingly. Sorting first stops you from porting a cron job into an agent framework.

By mid-November:run the new implementation in parallel with the old one and diff the outputs on real traffic. The export doesn't guarantee behavioral parity, so the only way to know is to compare.

November 30:the switch flips whether or not you're ready. Two weeks of slack is not padding, it's the minimum.