OpenAI Agent Builder: What It Builds, Its Shutdown, and When to Use Code Instead

OpenAI Agent Builder is a visual canvas for building agent workflows: you drag nodes such as an agent, a file search, a guardrail or an if/else onto a canvas, connect them, preview the run, and publish it to embed in your product through ChatKit. It is also closing. OpenAI told developers on 3 June 2026 that Agent Builder is deprecated, and it is scheduled to shut down on 30 November 2026. Existing users can keep using it during the transition. OpenAI’s recommended paths are the Agents SDK for applications you run yourself, or ChatGPT workspace agents for work that lives inside ChatGPT. So the practical question has changed from “should I use Agent Builder?” to “what do I move my workflow to, and how?”

What Agent Builder is

The Agent Builder guide↗ (opens in a new tab) describes a drag-and-drop canvas where you insert and connect nodes, and each connection becomes a typed edge. You can start from a template for a common pattern, such as a homework helper, or from a blank canvas. Preview runs the workflow interactively, lets you attach sample files, and shows each node executing. Work saves as you go, and publishing creates a new major version, a snapshot you can name in API calls.

The nodes

OpenAI’s node reference↗ (opens in a new tab) groups the building blocks into four kinds:

• Core: Start, which defines the workflow’s inputs; Agent, which holds instructions, tools, model configuration and optional evaluations; and Note, for comments on the canvas.
• Tools: File search over vector stores; Guardrails, which watches for personal data, jailbreaks, hallucinations and other misuse; and MCP, for calling third-party tools and services.
• Logic: If/else and While, written in Common Expression Language, and Human approval, which stops and asks the end user before a step goes ahead.
• Data: Transform, which reshapes an output, and Set state, which defines variables the whole workflow can use.

A typical example: a Start node takes a customer message, a Guardrails node screens it, a classifier Agent routes it with If/else to a billing agent or a support agent, the support agent searches the help-centre vector store, and a Human approval node sits in front of anything that issues a credit.

How workflows were deployed

There were two routes. The simple one embedded the published workflow in your product with ChatKit, OpenAI’s chat interface kit, with OpenAI hosting the workflow. The advanced one copied the workflow out as code, ran it on your own servers with the Agents SDK, and pointed ChatKit at that server. The ChatKit guide↗ (opens in a new tab) now steers new work to the second route: ChatKit is not being retired, but it recommends connecting it to your own server-side agent rather than to a hosted Agent Builder workflow.

Evals and guardrails inside it

Agent Builder let you run trace graders from its Evaluate menu, scoring runs of a workflow against criteria you set, and an Agent node could have evaluations attached. According to OpenAI’s deprecations page↗ (opens in a new tab), the Evals platform is being retired on the same timetable as Agent Builder: existing evals turn read-only on 31 October 2026, and the dashboard and API shut down on 30 November. OpenAI’s migration guide for Evals points to Promptfoo. If you rely on graders or eval datasets, export the test cases now while you can still read them.

The Guardrails node was a screen on input or output, not a permission system. It could stop a message that contained personal data or looked like a jailbreak, but it did not decide what a tool was allowed to change. The Human approval node did that job, and it is the part most worth rebuilding carefully when you move.

Its limits

• It is closing. Anything built on it has a fixed end date, and a published workflow has to be rebuilt elsewhere before then.
• The export is not a conversion. OpenAI’s migration guide says the export does not convert your workflow graph or guarantee that every behaviour transfers, and that control flow, triggers, tools and permissions need re-creating as you test.
• Determinism does not travel to ChatGPT. The same guide warns that workflows with strong determinism at their core may not migrate faithfully to a workspace agent.
• Connections are separate. Connected apps, authentication, publishing and permissions have to be reviewed again in whichever place the workflow lands.

Moving a workflow off Agent Builder

The steps in OpenAI’s migration guide↗ (opens in a new tab) are short. The work is in what comes after them.

1. Open the workflow in Agent Builder, choose Code in the top bar, choose Agents SDK, pick Python or TypeScript and copy the whole export.
2. Before changing anything, write down what each node did and run a handful of real inputs through the old workflow, keeping the outputs. They are your test cases.
3. Rebuild what the export leaves out: the If/else and While branches, the approval points, the state variables, and the credentials for each MCP server or tool.
4. Run the same inputs through the new code and compare. Keep the Human approval step as an approval in code, not as a line in the instructions.
5. If people used it through ChatKit, point ChatKit at your own server. If the workflow was really a ChatGPT task for your team, consider a workspace agent instead, which needs a Business, Enterprise or Edu workspace.

The Agents SDK primitives that the export maps onto, agents, handoffs, guardrails and sessions, are explained with a runnable example in the OpenAI Agents SDK in practice.

Agent Builder vs writing the code

• Seeing the flow: the canvas made branches and approval points visible to people who do not read Python. In code, a short diagram in the repository and one function per step does the same job.
• Changing it: in Agent Builder, a published version was a snapshot. In code, a change is a commit that can be reviewed, tested and reverted.
• Testing: trace graders ran inside the product. In code, the test cases live beside the agent and run in your own pipeline.
• Hosting: Agent Builder with ChatKit needed no server. Code needs somewhere to run, which is the real cost of moving.
• Longevity: the canvas ends on 30 November 2026. Code you own runs as long as you keep it running.

The general version of this choice, for anyone starting from scratch rather than migrating, is in how to build an AI agent.

Agent Builder vs n8n and similar workflow tools

If what you liked was the canvas, workflow automation tools are the nearest equivalent. They differ from Agent Builder in shape rather than quality, and whether that matters depends on the job:

• What sits at the centre: Agent Builder was built around agents calling OpenAI models. n8n is a general workflow tool with an AI Agent node inside it, next to ordinary app steps, and it supports several model providers in one workflow.
• Where it runs: Agent Builder ran on OpenAI’s platform. n8n can be used as a cloud service or self-hosted on your own servers.
• Approvals: Agent Builder’s Human approval node deferred to the end user. n8n’s human-in-the-loop for tools↗ (opens in a new tab) pauses before a chosen tool runs and sends the request to a reviewer on a channel such as Slack, Microsoft Teams or email, which can be a different person from the user.
• Triggers: an Agent Builder workflow began at its Start node, with inputs for a chat. Workflow tools such as n8n also start from schedules, webhooks and app events, which suits background jobs.
• Moving later: Agent Builder exported code. A workflow tool keeps the workflow in its own format, so moving away means rebuilding again.

A rough rule: if the workflow is mostly moving data between apps with an AI step in the middle, a workflow tool fits. If it is mostly an agent reasoning over tools, with a few fixed checks, code with the Agents SDK fits. If it is a repeatable task your team runs inside ChatGPT, a workspace agent fits.

Where the work gets recorded

Whichever route you take, an agent that does real work needs somewhere visible to report it. A task board is a good fit: the agent reads the task it was given and comments with what it did. fenbs is an MCP server, so code built with the Agents SDK can connect with a token issued by hand under Settings, and in n8n an agent reaches it through the MCP Client Tool node with a bearer token, while the plain MCP Client node↗ (opens in a new tab) does the same for a fixed step outside an agent; n8n AI agents covers both. Each change is recorded in the board’s history under the assistant’s name, and a person moves the task to Completed after checking it.