OpenAI Agent Builder Goes Dark Nov 30: Your Weekend Migration Plan

You got the email in June. You bookmarked the deprecation page. You told yourself you'd deal with it later. It is now later. On November 30, 2026, your Agent Builder workflow stops responding, your prompt templates return 410s, and your eval dashboards — already read-only since Halloween — go dark for good.

Don't panic. If you built one agent on top of Agent Builder, this is a weekend of focused work, not a quarter-long rewrite. The business logic is already yours. You're really just porting the orchestrator and the prompt text to something you own. Here's the calm version of that plan.

What exactly is going away

On June 3, 2026, OpenAI announced the shutdown of three products on the same timeline. All three stop functioning on Nov 30. Here's what each one did and what you lose:

• Agent Builder — the no-code visual workflow tool shipped at DevDay 2025. Drag-and-drop nodes, tool calls, handoffs. If you built an internal "assistant" with this, it stops executing on the deprecation date.
• Evals — the hosted evaluation platform for grading model outputs at scale. Already in read-only mode as of Oct 31, 2026. You can download results until Nov 30, then it's gone.
• v1/prompts API — the managed prompt-template endpoint. Prompts stored there return errors after cutoff.

Underlying model endpoints — the Responses API, Chat Completions, the function-calling interface — are not affected. Your access to GPT-class models stays exactly as it is. What's dying is the OpenAI-managed wrapper around those models.

Why this is happening to everyone at once

If you only follow OpenAI, this looks like a bad quarter. Zoom out and the pattern is unmistakable. Google is running a parallel deprecation: Vertex AI Extensions, the managed tool-calling framework for Gemini, stops working after Nov 26, 2026. Same month, same shape.

The read: hyperscalers raced to ship vendor-managed agent frameworks in 2024–2025, and in 2026 they're retreating to the layer they actually want to own — the model — and pushing the orchestration layer out to SDKs and open standards. That's rational from their side. From yours, it means every managed agent framework has a short half-life, and the vendor-lock-in tax is paid up front and again every time one of these sunsets.

Vendor-managed agent frameworks have a half-life of about eighteen months. Price your migrations in from day one.

If you want the broader context on why this layer keeps churning, we unpacked it in AI Agents in 2026: What Actually Shipped, What Flopped. The short version: managed frameworks demo great and age poorly.

The weekend migration checklist

This is the order we'd run it in for a team with one agent live. Do these in sequence; it will take Saturday afternoon through Sunday evening for most small apps.

• Audit what the agent actually does. Open Agent Builder. Write down every node, every tool call, every prompt. One page of plain English. Most "complex" workflows are five to seven nodes.
• Export your prompts to a text file. Copy every prompt template out of v1/prompts and Agent Builder into a prompts/ folder in your repo. Commit them. They are now versioned source code, not vendor-managed assets.
• Export your eval runs and the test cases that drove them. You'll need these as regression inputs for whatever eval tool you move to.
• Pick an orchestrator. See the table below. For most teams this is OpenAI Agents SDK (same models, least friction) or LangGraph (model-agnostic, bigger community).
• Rebuild the agent as code. Each Agent Builder node becomes a tool call or a step. If your workflow was six nodes, it's roughly 150–250 lines of Python or TypeScript.
• Point your prompts at the new orchestrator. Load them from your repo, not from a vendor endpoint.
• Re-run your old evals in Promptfoo. Same test cases, same scoring. Confirm you haven't regressed before you cut traffic over.
• Cut traffic over before Nov 30. Don't wait until the last day. Give yourself a week of real production traffic to notice anything weird.

Which successor should you pick?

Here's how the sunsetting frameworks map to realistic replacements. There's no single right answer; the right one depends on how much you want to stay inside OpenAI's ecosystem versus insulate yourself from the next deprecation.

If you're new to the orchestration layer, start with our walk-through in How to Build Your First AI Agent, and for the mental model behind why prompts, skills, and workflows are three separate things, see Prompts, Skills & Workflows: How AI Agents Actually Work.

The durable architecture: model, orchestrator, tools

If you only take one thing from this post, take this: the reason this migration hurts is that Agent Builder bundled three layers that should have stayed separate. The fix — the thing that keeps the next vendor sunset from costing you another weekend — is to pull them apart on the way out.

• The model layer. OpenAI, Anthropic, Google. Swappable. Call it through whatever SDK, but treat it as a commodity.
• The orchestrator layer. The thing that chains tool calls, handles retries, routes between models. Agents SDK, LangGraph, Claude Agent SDK. Also swappable — this is the layer that keeps dying.
• The tool layer. Your actual business logic: database queries, CRM calls, internal APIs. This is yours. Expose it over MCP (Model Context Protocol) and every agent framework on earth can call it without you rewriting a thing.

MCP is the piece that didn't exist in a serious form when Agent Builder shipped. The spec went stateless on July 28, 2026, and it's now hosted by the Linux Foundation — which is a quiet but important signal that it's not any one vendor's property. We walked through what MCP actually is, in plain English, in MCP (Model Context Protocol) Explained. If you build your tool layer on MCP today, the next deprecation hits one layer and leaves the other two alone.

What this is going to cost you

Honest numbers, assuming you have one agent in production and reasonable in-house engineering:

• Audit and prompt export — two to four hours.
• Orchestrator port (small agent) — eight to twelve hours of focused work.
• Eval re-wire in Promptfoo — two to four hours if your old test cases are in decent shape.
• Parallel-run and cutover — a few days of calendar time, mostly spent watching logs.

Agents with a lot of custom tool integrations, memory, or human-in-the-loop handoffs take longer. If you built on top of Agent Builder because you don't have a Python/TypeScript shop in-house, the port is doable but it's the moment to bring in help — the shape of the code matters a lot for what the next migration will cost you. If that's where you are, this is exactly the kind of thing we handle in our services engagements.

Where people go wrong (and when to call a pro)

The expensive mistakes we're already seeing on this migration aren't about the code:

If the agent you built on Agent Builder is doing something that genuinely matters — billable work, customer-facing automation, anything you'd notice at 2 a.m. — the value of a second set of eyes isn't the Python. It's catching the subtle behavioral regression before your customers do. And for context on how fast this pattern repeats, see Sora API Shutdown — same shape, different product, roughly two months earlier.

Frequently asked questions