If you built anything on OpenAI’s Agent Builder, you have a deadline now. The deprecation notice landed on June 3, and the visual workflow canvas — plus the dashboard Evals platform — shuts down for good on November 30, 2026. That’s roughly five months to move production code off a tool that was the centerpiece of OpenAI’s AgentKit pitch barely seven months ago.
Agent Builder launched in November 2025. So if you’re feeling whiplash, that’s fair. OpenAI sold a visual, low-friction way to wire up agent workflows, a lot of teams took the bait, and now the canvas is on the chopping block. The good news is that the underlying primitives you actually depend on — the Responses API, function calling, ChatKit — aren’t going anywhere. The bad news is that the migration is more rewrite than export button, and the official tooling is honest enough to tell you so.
Let me walk through what’s actually dying, where it goes, and how much work you’re really signing up for.
What’s deprecated and what survives
Two things are being retired, and they shut down on the same day.
Agent Builder — the visual workflow editor where you drag nodes, wire tools, and set guardrails — goes dark November 30, 2026. You can keep using it during the transition window, but no new investment is coming and the lights go out at the deadline.
The dashboard Evals platform — OpenAI’s hosted eval runner — goes read-only on October 31, 2026, then shuts down with everything else on November 30. The one-month read-only window is your last chance to export test cases and results before they’re gone, so treat October 31 as the real deadline, not November 30.
Here’s what keeps working, which matters a lot for scoping the job:
- The Responses API — the actual model-calling layer. Untouched.
- Function calling / tools — the mechanism your agents use. Untouched.
- ChatKit — the chat UI framework. This survives, but with a catch I’ll get to.
So you’re not re-architecting your whole stack. You’re replacing the orchestration layer (Agent Builder) and the testing layer (Evals). The model calls underneath stay the same. That’s the difference between a painful week and a painful quarter.
Why OpenAI did this
The short version: OpenAI is consolidating away from a visual, hosted builder toward code-first agents. The two paths they’re pushing are the Agents SDK (build in code) and ChatGPT Workspace Agents (build in natural language, share with a team). The drag-and-drop canvas sat awkwardly between those two, and it lost.
There’s a pattern here worth naming. Last year OpenAI deprecated the Assistants API. Now AgentKit’s visual layer. If you’ve been on the platform a while, you’ve now lived through enough of these to spot the tell: OpenAI ships an abstraction, watches how people use it, then collapses it into something closer to the raw API and walks away from the abstraction. Betting your architecture on the abstraction has been the losing move every time.
The ChatKit catch fits this story. ChatKit “survives,” but the community thread on the deprecation makes clear the recommended setup is shifting: instead of OpenAI hosting the backend for you, you run ChatKit on your own infrastructure using the ChatKit Python SDK, connected to whatever agentic backend you want. One developer in that thread called the self-hosting requirement “economically unviable” for agencies juggling multiple small client projects, and asked OpenAI to open-source the pieces instead. I’m sympathetic. The managed-backend convenience was half the reason to use it.
Moving Agent Builder workflows to the Agents SDK
Agent Builder gives you an export. Don’t trust it to do the whole job.
You can select Code > Agents SDK inside Agent Builder and export to TypeScript or Python. Useful starting point. But OpenAI’s own migration guide says the quiet part out loud: the export “does not convert your workflow graph or guarantee that every behavior transfers unchanged.” Translation — it’ll scaffold something, but you own the correctness.
The parts that need hand-work, straight from the migration docs:
- Control flow has to be recreated. Branching, loops, conditional routing between nodes — the visual graph’s logic doesn’t come across cleanly.
- Triggers need reconfiguring. However your workflow got kicked off, you wire that yourself now.
- Tools and permissions get re-set up. Each tool the agent could call, plus its access scope.
- Authentication is reconfigured from scratch.
The line that should set your expectations: “Workflows with strong determinism at their core may not migrate faithfully.” If your Agent Builder flow was really a deterministic state machine that happened to call a model at a couple of steps, you’re going to feel that. A canvas with hard branching logic doesn’t map onto an LLM-driven agent loop without you making decisions about what stays code and what becomes a prompt.
In practice the SDK version is plain code: you define an agent, give it tools as functions, set instructions, and run it. Something like:
from agents import Agent, Runner, function_tool
@function_tool
def lookup_order(order_id: str) -> str:
# your existing tool logic
...
support_agent = Agent(
name="support",
instructions="Resolve order issues. Escalate refunds over $200.",
tools=[lookup_order],
)
result = Runner.run_sync(support_agent, "Where's order 8842?")A clean, lightly-branched workflow with two or three tools? Plan for a day or two, most of it spent re-implementing guardrails and re-testing. A sprawling multi-agent canvas with deterministic routing and a dozen tools? Budget a couple of weeks and assume behavior will drift until you’ve tested it against real traffic. The export saves you typing, not thinking.
If you’re weighing the Agents SDK against alternatives while you’re forced into the code anyway, I wrote a fuller comparison of the main agent frameworks — LangGraph, CrewAI, the OpenAI Agents SDK, Pydantic AI, and Mastra — that’s worth a read before you commit.
Moving Evals to Promptfoo
OpenAI is pointing Evals refugees at Promptfoo, and honestly it’s a reasonable landing spot. It’s open source, it runs locally and in CI, and it’s not going to get deprecated out from under you by a single vendor’s roadmap.
The mental model is different, though, and that’s where the friction lives. Dashboard Evals was a hosted thing — you defined test cases and graders in OpenAI’s UI, ran them on their infrastructure, looked at results in their dashboard. Promptfoo is config-as-code. You write a YAML file, commit it, run promptfoo eval, and the results live in your repo and your CI logs.
A minimal config looks like this:
prompts:
- "Summarize this support ticket in one sentence: {{ticket}}"
providers:
- openai:gpt-4o
tests:
- vars:
ticket: "Customer can't reset password, link expired twice"
assert:
- type: contains
value: "password"
- type: llm-rubric
value: "Summary is one sentence and mentions the reset problem"The porting work breaks into three buckets:
Test cases. Your inputs and expected behaviors move into the tests block as vars and assert entries. If you exported your dataset before October 31, this is mostly mechanical reshaping — script it if you have hundreds of cases.
Assertions. This is the part that doesn’t map one-to-one. Exact-match and contains-style checks port trivially. Anything that leaned on OpenAI’s hosted graders becomes a Promptfoo assertion type — llm-rubric for model-graded checks, javascript for custom logic, similar for embedding distance. You’ll rewrite the grading intent, not copy it.
CI integration. This is where Promptfoo is actually an upgrade. Dashboard Evals lived in a browser. Promptfoo drops into a GitHub Action or any CI runner and fails the build when quality regresses, which is where eval gates belong. If you were running Evals manually before a release, moving to CI is the rare migration that leaves you better off.
One real gotcha: model-graded assertions cost tokens every run. Dashboard Evals hid that behind the platform. With Promptfoo you’re paying for those grader calls directly, so a 500-case suite with llm-rubric on every case adds up fast in CI. Cache aggressively and don’t grade-by-LLM what a string match could catch.
The fork in the road: re-platform now, or stay?
Here’s the decision you actually face. You’re being forced to touch this code regardless. Do you migrate to OpenAI’s new tools (Agents SDK + Promptfoo) and stay mostly in their ecosystem, or do you use the forced rewrite as the moment to go vendor-neutral?
The case for re-platforming is the deprecation itself. You just got burned. Agent Builder was the recommended path in November and a dead end by June. If you move orchestration to something like LangGraph or Pydantic AI and evals to Promptfoo plus an observability layer, the next time OpenAI reshuffles its lineup it’s a config change — swap the model string — not a rewrite.
The case for staying is pragmatism. The Agents SDK is genuinely good, the export gives you a head start, and Promptfoo is already vendor-neutral, so you’re half-decoupled without doing anything heroic. If your team is small and you’re not running multi-provider, a full re-platform onto LangGraph is a lot of yak-shaving to solve a problem you might not have.
My take: split the decision. The evals layer is a no-brainer to make portable — Promptfoo is provider-agnostic out of the box, so you get that for free. The orchestration layer is the judgment call. If you’re a two-person team shipping one product on GPT models, take the Agents SDK and move on; abstracting for a hypothetical future migration is premature. If you’re an agency or you already run more than one model provider, eat the cost now and put a real abstraction between your business logic and the agent runtime. The lock-in tax compounds, and you just saw the bill.
While you’re rethinking the stack, put real observability in. The deprecation pain is so much worse when you can’t see what your agents are doing in production. I compared the LLM observability and gateway options — Langfuse, Helicone, Portkey, LiteLLM, OpenRouter — and a gateway like LiteLLM in front of your calls is exactly the kind of seam that turns the next provider switch into a one-line change.
Structure your code so the next deprecation is a config change
The lesson here isn’t “OpenAI bad.” Every platform deprecates. The lesson is architectural: keep your business logic ignorant of the vendor.
A few habits that would’ve blunted this migration:
- Wrap the agent runtime behind your own interface. Your app calls
run_agent(task), not the OpenAI SDK directly. When the runtime changes, you change one adapter. - Keep tools as plain functions. A tool that’s just a Python or TypeScript function with typed args ports to any framework. A tool defined inside a vendor’s visual node doesn’t.
- Treat prompts and evals as files in your repo, not artifacts in someone’s dashboard. Anything that lives only in a vendor UI is something you’ll be scrambling to export at a read-only deadline. Ask anyone exporting Evals datasets before October 31 how that feels.
- Put a gateway in front of model calls. It’s the cheapest insurance against the next “the API you built on is now deprecated” email.
None of this is exotic. It’s the same decoupling discipline you’d apply to a database or a payment provider. Agents just feel new enough that people skip it.
The short version, by situation
If you went light on Agent Builder — a couple of simple workflows — export to the Agents SDK, spend a day or two cleaning up control flow and guardrails, move evals to Promptfoo, done before July. If you went deep, start now: inventory every workflow, export your Evals data before October 31, scope the determinism-heavy flows first because those fight the migration hardest, and seriously consider whether a vendor-neutral orchestration layer is worth the extra week.
Either way, the two dates that matter are October 31 (Evals read-only — last call to export) and November 30 (everything off). Put them on the calendar today.
Pick your single most business-critical Agent Builder workflow and try the SDK export on it this week. You’ll learn more about the real effort from one honest migration than from any checklist — including this one.