OpenAI Agent Builder alternatives before the November 30 shutdown

OpenAI is shutting down Agent Builder on November 30, 2026. Developers who built on it were told on June 3, and the visual canvas that turned agent logic into nodes and arrows goes away at the end of this month. ChatKit, the embeddable chat front end, stays.

If you have workflows in Agent Builder, you have weeks, not quarters. Here is what OpenAI recommends, the other places those workflows can go, and how to choose.

What Agent Builder did

Agent Builder was a canvas for multi-step agent workflows. You placed nodes, joined them with typed edges, and published a versioned workflow. The node set covered most of what an agent needs:

• Core: Start, Agent, Note
• Tools: File search, Guardrails, MCP
• Logic: If/else, While, Human approval
• Data: Transform, Set state

You could preview a run with sample files and grade traces before publishing. A published workflow went live through ChatKit, by its workflow ID, or you downloaded its SDK code and ran it yourself.

That download is your bridge out. Do it before the 30th.

What OpenAI recommends

OpenAI's deprecation notice points to two destinations.

The Agents SDK. Code, in your own application. It gives you agents with instructions and tools, handoffs between agents, guardrails on inputs and outputs, sessions that keep working context, built-in ways to involve a person during a run, and tracing. You own deployment, storage and approvals.

ChatGPT workspace agents. Agents built inside ChatGPT, generally available on Business, Enterprise and Edu. You pick the model and reasoning effort, connect apps, tools and custom MCP servers, share the agent with your team, use it in Slack, run it on a schedule or trigger it through an API.

Both are reasonable homes. One asks you to become the platform team; the other moves the workflow into ChatGPT.

The alternatives at a glance

Where each one fits

Stay with OpenAI, in code: the Agents SDK. If your Agent Builder workflow was mostly agents and handoffs, the SDK is the shortest path, and the exported code is a starting point. Plan for the runtime questions that come with owning the code: where state lives between turns, how approvals reach a person, and what happens when your process restarts mid-run.

Your users already live in ChatGPT: workspace agents. For internal agents that answer questions and act across company tools, keeping them in ChatGPT avoids building a front end at all. The trade is that the workflow lives inside ChatGPT's agent model, on its plans.

You want a canvas and a big integration catalog: n8n. n8n is the closest in feel to Agent Builder. Its human-in-the-loop for AI tools pauses the workflow when an agent wants a gated tool and sends the request to a reviewer in Slack, Discord, Telegram, Microsoft Teams, Gmail, Outlook, WhatsApp, Google Chat or n8n's own chat. Cloud plans start at €20 a month billed annually for 2,500 workflow executions, and the Community Edition is free to self-host.

Long-running, stateful, code-first: LangGraph. LangGraph describes itself as a low-level orchestration framework for long-running, stateful agents, with durable execution and human-in-the-loop. An interrupt() pauses the graph and Command(resume=...) continues it, provided you configured a checkpointer. One detail to design for: on resume, the node restarts from its beginning, so LangGraph's docs advise making side effects before an interrupt idempotent.

Where Momor fits

Momor Workflows suits Agent Builder users whose agents were really processes: read something, check a system, ask a person, act, reply. Three things carry over cleanly.

A canvas, if you want one. The Workflow Designer shows a workflow as a flow and as YAML, side by side, and both are the same definition. Steps cover asking a model, using a tool, branching, looping over a list, asking a person and responding, with hooks that act when a run ends or flags something a person should know. You can also build definitions with a C# builder and export any version as YAML or C#.

Approvals that can wait for days. A Wait step puts a question to a person, and the run keeps its place until they answer, holding no worker while it waits. Every step is written to the run's record before it counts, so after a restart the run continues from the first step that did not finish, and finished steps never run twice. A connected tool can be marked as needing approval: the call waits until the run's owner allows it, or refuses with a reason the run is told.

ChatGPT as the front end, with the logic outside it. Momor serves an organization's chosen workflows as MCP tools at the organization's own address. ChatGPT, claude.ai and other MCP clients sign the person in through OAuth, and each run belongs to that person. When a run needs an answer, the question goes back to the client as an MCP elicitation, a form the person fills in, where the client supports it.

Underneath, every model call goes through Momor Gateway, so each step can use a different model from a different provider, and a call moves to another provider when one fails.

What to weigh: runs start from an API call, Momor's Chat, or an MCP client. There is no schedule, email or webhook starter yet, so a timed run is started by your own scheduler. Connecting an MCP server to your organization is done with Momor's help for now, and Workflows is priced by agreement, based on the workflows you run.

A migration checklist

1. Export every published workflow's code before November 30.
2. List what each node touched: MCP servers, file search stores, guardrails, state.
3. Mark every place a person approves, and decide who answers and where.
4. Decide where the conversation lives: ChatKit, ChatGPT, your own app, or an MCP client.
5. Run real cases through the new home before the old one disappears.

If your workflows need to wait for people, survive restarts and keep a record of every step, start with the Workflows quickstart or talk to us.