OpenAI Is Retiring Agent Builder: What to Do Now

Agent Builder, OpenAI's drag-and-drop tool for wiring up AI agents, launched at DevDay in October 2025. On June 3, 2026, OpenAI announced it is being deprecated, and it goes dark for good on November 30, 2026. The Evals platform and reusable Prompts are on the same clock. That is roughly a thirteen-month life for a product plenty of teams built real workflows on. The recommended exit is the code-first Agents SDK, or the newer ChatGPT Workspace Agents.

If you assembled your agent by clicking boxes and connecting arrows, this is a fire drill with a deadline. If you did not, it is still worth reading, because the same thing will happen to whatever visual builder you pick next. The useful question is not "which no-code tool do I move to." It is "how do I make sure the next sunset costs me an afternoon instead of a quarter." This is a pattern, not a one-off, and the studios that came through it cheaply are the ones who treated the builder as a convenience, not as the place their logic lived.

What OpenAI is actually shutting down

Three things are going away on November 30: the visual Agent Builder canvas, the Evals platform, and reusable Prompts. ChatKit, the embeddable chat UI, stays. The models stay. The Responses API and the underlying tool-calling stay. What you lose is the visual layer that held your workflow together, the graph of nodes that decided which tool ran when, how handoffs happened, and what the instructions were at each step.

OpenAI's migration path is an export button: open a workflow, choose Code, pick the Agents SDK in TypeScript or Python, and copy out what it generates. That gets you the skeleton. It does not carry everything. Anything you configured in the UI that does not map cleanly to SDK code, and anything you were relying on the platform to remember for you, has to be rebuilt and re-tested by hand. Teams that used the canvas to prototype tool chains and handoff flows will find the export is a starting point, not a finished port.

The real lesson: your agent logic is the asset

Here is the part that outlives this specific announcement. An AI agent is not the model, and it is not the pretty canvas you built it on. It is a small pile of decisions: what the system prompt says, which tools the agent can call and with what permissions, how it decides between them, what happens when a tool fails, when a human gets pulled in, and how you know whether any of it worked. That logic is the thing your business actually paid for.

When that logic lives inside a vendor's visual editor, you do not own it in any portable sense. You own a diagram in their format, and the day they change direction, your diagram is worth what their export button decides to give you. When the same logic lives in code you control, in a repository you can read, a platform sunset becomes a dependency swap: you change the client library, keep your prompts, tools, and tests, and move on. We made this case before Agent Builder even had a shutdown date, in no-code AI agent builder vs custom build, and the June announcement is the argument writing itself.

This is not an anti-no-code position. No-code builders are genuinely good for proving an idea in a week. The mistake is letting a proof-of-concept quietly become production without anyone deciding that on purpose.

How to tell if you are exposed

Not every use of Agent Builder is a problem. Run through a short checklist:

• Is it in production? A demo you can rebuild in a day is not a risk. An agent handling live customer messages or moving real invoices is.
• Where do your prompts and tool definitions live? If the only copy is inside the builder, you have no backup and no version history. That is the sharpest exposure.
• Can you reproduce the agent's behavior without the UI? If nobody on the team can explain, in code or plain steps, what the agent does at each turn, the export will not save you.
• What breaks if it stops tomorrow? Trace the workflow to a real business process. If the answer is "support stops triaging" or "orders stop routing," you have a deadline, not a someday.

If any of those land badly, put a date on the migration now while the export tooling still works and the platform is still up. The worst version of this is a scramble in late November when the canvas is read-only.

Migrating off without a fire drill

Treat it as a normal software port, because that is what it is. First, export what Agent Builder gives you and read it, do not just run it, so you understand what the canvas was doing on your behalf. Then rebuild the missing pieces deliberately: the error handling, the human-in-the-loop checkpoints, the guardrails that were toggles in the UI and are now code you have to write and own.

The Evals shutdown matters as much as the builder here. If you were checking your agent's quality inside OpenAI's Evals, you need somewhere else to run those tests before November, or you will be shipping the migration blind. Port your eval cases into your own test suite so you can prove the rebuilt agent behaves like the old one, not just that it runs. The frameworks worth landing on are the code-first ones, the Agents SDK, LangGraph, and the others we compare in choosing an AI agent framework, all of which keep your logic in a repository instead of a vendor's canvas.

And model the running cost while you are in there. AgentKit had no subscription, but every model and tool call is metered, and a busy production agent bills continuously. A migration is a good moment to check the real number against the value, the way we lay out in the true cost of running AI agents.

Build so the next sunset is a non-event

The teams shrugging at this announcement are the ones who already own their agent as code. Their prompts are in version control. Their tools are typed functions with tests. Their evals run in their own CI. For them, "OpenAI is retiring Agent Builder" is a one-line dependency bump, not a project.

That is the target state, and it is reachable whether you start on a no-code tool or not. Prototype fast on whatever is quickest, but the moment an agent is going to production, move the logic somewhere you control and wrap it in tests. Then the next time a vendor changes direction, and there will be a next time, it costs you an afternoon.

If you are staring at an Agent Builder workflow and a November deadline, we can help you port it to something you own and keep it behaving the way it does today. Tell us what you built and where it runs, and we will map the migration with you.