OpenAI Agent Builder: Shutdown Date and Alternatives

OpenAI Agent Builder is a visual canvas for building multi-step agent workflows, and OpenAI has announced it will shut down on 30 November 2026. ChatKit, the embeddable chat UI, stays. If you use it, export to the Agents SDK or ChatGPT Workspace Agents before that date. Checked 31 October 2026.

At a glance

The most important fact: it is going away

Most search results and videos about Agent Builder describe it as a new product. That is out of date. Every page of OpenAI's current guide opens with the same notice: OpenAI is deprecating Agent Builder, existing users can keep using it during the transition window, and it is scheduled to shut down on 30 November 2026.

The deprecations page gives the timeline:

That matters most for two groups. If you have a workflow in production, plan the move now, because there are about four weeks left from the date we checked. If you are choosing a tool for a new agent, do not start here. The rest of this page explains what it does so you can recognize the workflow when you recreate it elsewhere, and where to go.

What Agent Builder does

The guide describes it as "a visual canvas for building multi-step agent workflows." You start from a template or a blank canvas, drag nodes onto it, give each step typed inputs and outputs and preview runs on live data. When it works, you publish it and deploy it.

A workflow is a combination of agents, tools and control-flow logic. The three steps from the guide:

1. Design the workflow in Agent Builder.
2. Publish it. The result is an object with an ID and versioning. Each publish creates a new major version, a snapshot.
3. Deploy it. Either pass the workflow ID into ChatKit, or download the Agents SDK code and run it yourself.

Each connection between nodes is a typed edge. Clicking a node shows its inputs and outputs, so you can see the data contract between steps and check that the next node receives the fields it expects. The editor autosaves.

You can also test it. Preview lets you run the workflow interactively, attach sample files and watch each node execute. The Evaluate tab runs trace graders on a trace or set of traces, with custom graders for overall workflow performance.

The node types

The node reference sorts nodes into four groups.

Core nodes

The guide advises keeping each agent narrowly scoped. Its homework-helper example uses one agent to rewrite the query, another to classify it as Q&A or fact-finding, and a third for each type of question.

Tool nodes

Logic nodes

The guide's example for human approval is an agent that drafts an email. A human approval node asks "Would you like me to send this email?" and, if approved, passes to an MCP node connected to Gmail.

Data nodes

Safety advice that still applies

OpenAI's safety page is worth reading even if you leave the product, because the advice applies to any agent workflow. Its two named risks are prompt injection (untrusted text trying to override instructions) and private data leakage. The mitigations:

• Do not put untrusted variables into developer messages. Pass them through user messages, since developer messages take precedence.
• Use structured outputs between nodes (enums, fixed schemas, required fields) so there is no freeform channel to smuggle instructions through.
• Steer the agent with clear policy and examples, because it can misunderstand or hallucinate.
• Use guardrails and human approval before actions that matter.

The page adds that "even with these mitigations, agents won't be perfect and can still make mistakes or be tricked."

ChatKit: what stays

ChatKit is OpenAI's framework for embedding chat. It offers embeddable UI widgets, customizable prompts, tool-invocation support, file attachments and visualizations of the model's reasoning. It has two paths:

• Custom server integration. Run ChatKit on your own infrastructure with the ChatKit Python SDK and connect it to any agentic service, including one built with the Agents SDK.
• Existing Agent Builder-hosted integration. If your ChatKit already points at an Agent Builder workflow, it keeps working during the transition window.

For new work, OpenAI says to use advanced ChatKit integrations with your own server-side agent, which is the direction its docs now point.

How to move off it

OpenAI's migration guide has two options. First, export:

1. Open the workflow in Agent Builder.
2. Select Code in the top navigation.
3. Select Agents SDK.
4. Choose TypeScript or Python and copy the complete export.

Then choose:

For Workspace Agents, you paste the exported code into the workspace agent creator with a prompt such as "Please help me convert this workflow into an agent". Then review the generated instructions, configure apps, tools, skills and permissions, use Preview on representative inputs and select Create only after you have validated the result.

OpenAI is plain about the limits. The export "does not convert your workflow graph or guarantee that every behavior transfers unchanged." Workflows with strong determinism at their core may not migrate faithfully to a workspace agent, and connected apps, authentication, publishing and permissions need separate review. Plan for a rebuild of control flow and a test pass, not a copy-paste.

See our OpenAI Agents SDK page for the code route.

A practical migration plan

Because the deadline is fixed, treat this as a small project with dates.

Two habits help. First, write down the expected output for five or ten real inputs before you migrate, so you can judge the new version against something fixed. Second, if the workflow includes a human approval node, check that the new runtime still pauses before the risky action. That step is easy to lose in a conversion and expensive to lose in production.

If a workflow was mostly a single agent with a few tools, the Agents SDK route is usually small. If it was a long graph with many branches, the explicit statement that the graph is not converted is your warning to budget real time.

Where each node goes in code

A graph does not convert, but its parts have counterparts in the Agents SDK. This table is our mapping from the node reference above and the SDK documentation. Use it as a checklist when you rebuild.

Notice what the table lacks: triggers, publishing, permissions and the hosted endpoint. The export does not carry those, so they are the first things to rebuild. Decide how the workflow is called now, whether from a web form, a queue or ChatKit, and who may call it.

A parity test for the migration

The surest way to know a rebuild works is to run the same inputs through both versions and compare. Save five to ten real inputs with the outputs you accepted from the old workflow. Then write a short script that runs each input through the new agent and prints both answers next to each other for a person to judge.

import asyncio
import json

from agents import Runner

from my_agents import triage_agent  # your rebuilt entry agent


async def main() -> None:
    cases = json.load(open("parity_cases.json"))
    for case in cases:
        result = await Runner.run(triage_agent, case["input"])
        print("INPUT   :", case["input"])
        print("OLD     :", case["accepted_output"])
        print("NEW     :", result.final_output)
        print("-" * 40)


asyncio.run(main())

The file parity_cases.json is a list of objects with input and accepted_output keys. Judge by eye on the first pass, since two correct answers rarely match word for word. Mark each as same, better or worse, and fix every "worse" before you cut over. Include at least one input designed to trip each guardrail, and one that needs approval, because those are the behaviours that fail quietly in a conversion. Run the set again after each prompt change, and again on the day you switch.

Telling the people who depend on it

A shutdown is also a communication task. If your workflow serves customers or colleagues, a short plan avoids surprises.

1. Name an owner for each workflow and a date by which it is rebuilt.
2. Warn users early if the new version will answer differently, and say what stays the same.
3. Keep the old one running until the new one has passed the parity test and run in parallel for a few days. Remember the old one stops on 30 November 2026, so the overlap must fit before that date.
4. Archive the export and the notes. Commit the exported code, the saved test inputs and a short README that says what the workflow did and why. A record of the intent is worth more than the code if you rebuild again later.
5. Update every page that mentions it, including documentation, tutorials and internal wikis.

Choosing a builder you will not have to leave

The shutdown is a useful prompt to ask a few questions of whatever replaces it. Can you export the workflow in a format another tool can read? Can you run it on infrastructure you control? Is the source available, and under what licence? Who pays for it if the vendor changes its pricing? Does the tool keep your data under terms you accepted? A self-hosted builder such as n8n answers more of these in your favour than a hosted one, though its fair-code licence has its own limits. A code framework answers all of them, at the price of writing code. None of this makes any tool permanent. It makes the exit cheaper, and that is the part you can control.

Alternatives

If you want a visual builder rather than code, the options differ by how much they are tied to one vendor.

For the wider field see AI agent platforms and AI agent frameworks.

Who should still care

• You have a live workflow. Export now, test the export, then decide between the SDK and Workspace Agents.
• You wrote a guide or course on it. Add the shutdown notice at the top.
• You are comparing platforms. Treat Agent Builder as a design reference. Its node vocabulary (agent, guardrails, approval, transform, state) is a clean checklist for what any builder should offer.

Limits and questions we could not answer

• Pricing. The pages we read describe the product but do not state a separate Agent Builder price. Usage of models and tools is billed at normal rates, and we did not read the ChatKit or file search billing pages.
• After shutdown. The docs say what is scheduled for 30 November 2026, not what happens to stored workflows afterwards. Export before then.
• Hosted ChatKit workflows. They work during the transition window. We found no statement on whether hosted workflow IDs stop working on 30 November 2026, so plan as if they do.

Our take

This is a reading of OpenAI's own documentation and deprecation page. We did not build a workflow for this page.

The useful lesson is about risk. A visual builder tied to one vendor's hosting can disappear on a few months' notice, and the exit route here is an export that explicitly does not guarantee identical behavior. If you build agent workflows, favor tools whose output you can run on your own infrastructure: an SDK, an open-source builder, or a code framework.

The product's ideas are sound, though. Typed edges, preview with live data, guardrails as nodes and a human approval step are all worth copying in whatever you use next. For a new project we would start in code with the Agents SDK, or in a self-hostable builder such as n8n, and keep the workflow in version control.

Checklist

• List every Agent Builder workflow and who depends on it
• Export each one from Code, then Agents SDK
• Choose SDK or Workspace Agents per workflow
• Recreate control flow, triggers, tools and permissions, then run representative inputs
• Keep guardrails and human approval where actions are risky
• Finish before 30 November 2026