OpenAI is retiring Agent Builder on November 30, 2026, and there is no self-hosted version to fall back on — so every agent you built on that canvas has to be rebuilt somewhere else before then. The announcement landed on June 3, 2026 and also covers the hosted Evals platform and reusable Prompts objects. ChatKit survives. The canvas does not. As of today that leaves 102 days.
We started auditing client agents the week the notice went up, and the pattern was consistent enough to be worth writing down: the teams in trouble aren't the ones who built something complicated. They're the ones who built something they can't see anymore.
What exactly is being shut down
Three things went onto OpenAI's deprecations page on the same day, all with a November 30, 2026 end date:
- Agent Builder — the visual, drag-and-drop agent canvas. Shuts down November 30, 2026. OpenAI points you to the Agents SDK or to Workspace Agents in ChatGPT.
- The Evals platform — the hosted evaluation dashboard and API. Staged sunset: existing evals go read-only on October 31, 2026, then the dashboard and API close November 30. Recommended replacement is Promptfoo.
- Reusable Prompts — the
v1/promptsprompt objects. Also November 30. Recommended replacement is "move the prompt into your application code," which is a polite way of saying you're on your own.
And the one thing that isn't going anywhere: ChatKit remains available. The embeddable chat UI stays. That's a bigger deal than it sounds, and I'll come back to it.
Why this hits agencies harder than it hits engineering teams
An engineering team that built on Agent Builder still has engineers. They read the notice, groan, and port the thing to the Agents SDK in a sprint. Annoying, not existential.
Agencies are in a different position, and it's worth being blunt about why: Agent Builder was attractive precisely to the people least equipped to migrate off it. It was a visual canvas. You could hand it to a strategist. You could sit next to a client and change a prompt live on a call. That accessibility is the entire reason it got adopted in agency workflows, and "port it to a Python framework" removes exactly that property.
There's a second problem that's easy to miss until you go looking. Agent Builder is a hosted product with no meaningful export path. Your workflow isn't a file sitting in a repo somewhere — it's a drawing on someone else's server. When we started the inventory pass on client accounts, the actual first task was people taking screenshots of node graphs. In 2026. That's the real lesson buried in this deprecation, and I'll get to it at the end.
The three migration paths, and who each one is for
- OpenAI Agents SDK. The official code-first path, Python or TypeScript, on the Responses API. Right answer if you have engineers, the agent is genuinely a software artifact, and you're happy being locked to OpenAI models. Wrong answer if the visual canvas was the point.
- Workspace Agents in ChatGPT. OpenAI's no-code suggestion. Fine for internal, prompt-shaped tasks. Not fine for anything that needs to run on a schedule, write to a client's CRM, or be operated by anyone other than the person who built it.
- A general workflow platform you host yourself. n8n, in our case. Keeps the visual model, keeps the tool integrations, removes the single-vendor dependency that caused this whole problem.
We've moved every affected client agent to the third option. Not because n8n is objectively better than the Agents SDK at everything — it isn't, and we've written about where n8n actually breaks and you should reach for LangGraph instead — but because the failure mode we just experienced was platform risk, and porting from one closed hosted product to another closed hosted product doesn't fix it.
Why we default clients to self-hosted n8n
Three reasons, in the order they matter to a client:
You keep the artifact. An n8n workflow is JSON. It lives in a repo, it diffs in a pull request, and if n8n the company disappeared tomorrow, the instance on your own server keeps running. That's not a theoretical benefit anymore — we just watched the alternative play out.
The concepts port almost one-to-one. Agent Builder's agent node maps to n8n's AI Agent node. Tool calls map to Execute Sub-workflow tools. Routing maps to Switch and IF. If you keep your tool names identical, most of your system prompts move over unedited. The migration is tedious, not clever.
It stays visual. The strategist who could edit the Agent Builder prompt can still edit the n8n prompt. You don't lose the operating model that made the thing useful to a non-engineer in the first place.
The honest cost: you're now responsible for the guardrails OpenAI was giving you for free. Agent Builder shipped PII detection, jailbreak detection, off-topic checks, and schema validation as drag-in nodes. In n8n those are sub-workflows you write. Budget for that — it's usually the single largest chunk of the migration, and it's the part people forget when they scope it at "a day or two."
The part nobody's talking about: ChatKit stays
This is the detail that makes migrations survivable, and it's buried in the middle of the deprecation notice.
ChatKit — the embeddable chat widget — is explicitly not part of the wind-down. So if you shipped a client an agent as a chat bubble on their site, the visible product does not have to change at all. You keep the widget, you keep the styling, you keep the URL. You swap the backend from an Agent Builder workflow to an n8n endpoint and the end user never knows a migration happened.
For a lead-gen page doing real volume, that difference is everything. "We're rebuilding your chatbot" is a conversation with a client. "We moved some infrastructure behind the scenes, nothing changes on your site" is not.
If you want the agent to be callable from more than a chat widget, expose the n8n side over MCP instead — we walked through the three ways to wire n8n and MCP together, and the MCP Server Trigger node supports bearer and header auth out of the box.
Do the eval export first, not last
The date people are circling is November 30. The date that will actually hurt you is October 31, when existing evals go read-only.
Your eval set is the only thing that lets you prove the migrated agent behaves like the original. Without it you're shipping a rebuilt agent to a client on vibes, and "it seemed fine when I tested it" is not a thing you want to say when a voice agent starts quoting the wrong price. Pull the datasets and grader configs out now, drop them into Promptfoo or any harness you control, and run the old agent against them once so you have a baseline to compare to.
We treat this as non-negotiable on client work for the same reason we test agents against a fixed suite before they ever touch production. A migration is a rewrite. Rewrites need a regression suite.
The 102-day plan we're running
Working backwards from November 30, this is the schedule on our board:
- Now through mid-September — inventory. Every workflow screenshotted, every prompt and tool definition copied into a repo, every eval dataset exported. This is unglamorous and it is the whole ballgame.
- Mid-September through mid-October — rebuild. One agent at a time in n8n, guardrails included, tool names preserved. Nothing goes live yet.
- Mid-October through mid-November — parallel run. Mirror real inputs into the n8n version with actions disabled, diff outputs against the live Agent Builder version, fix disagreements.
- Mid-November — cut over. Repoint ChatKit, watch error rates for 48 hours, archive the old workflow.
- Leave two weeks of slack. Something will run long. Something always does.
If you're starting this in November, skip the parallel run and accept that you're going to find bugs in production. That's the tradeoff, and it's better than being dark on December 1.
What this should actually change about how you build
The lesson isn't "OpenAI is unreliable." Every platform deprecates things. The lesson is narrower and more useful:
If you can't export it, you don't own it. Before you build a client's core workflow on any hosted canvas, ask the boring question — if this product disappeared in six months, what would I have? If the honest answer is "screenshots," price the platform risk into the decision or don't take it. That question costs nothing to ask and it's the difference between a migration and an outage.
It's the same reasoning that led us to move clients off Zapier and Make onto self-hosted infrastructure years ago — that migration playbook is almost identical to this one, which tells you something. And it's why the cost conversation about building agents should always include where the thing lives, not just what it costs to build.
Get your agents off the clock
If you have anything running on Agent Builder, the useful next step is an inventory, not a rebuild — you need to know what you're actually exposed to before you can scope the work.
That's what we do in a free automation audit: we map every agent and workflow you're running, flag the ones sitting on a deprecation clock, and hand you a migration plan with real dates. No pitch deck. If your agents are fine where they are, we'll tell you that too.
Get a Free Automation Audit — or read more about how we build and host AI agents that don't depend on someone else's roadmap.