OpenAI Is Shutting Down Agent Builder. How I Build Automations That Survive the Vendor

OpenAI introduced Agent Builder in beta on 6 October 2025. It announced deprecation on 3 June 2026, roughly eight months later. Shutdown is scheduled for 30 November 2026. Those are the dates in OpenAI’s launch update and deprecation timeline, checked on 7 October 2026.

Eight months describes the time to the announcement. The scheduled shutdown is more than a year after launch. That distinction matters when deciding how much time a migration has left.

I build automation around the work it must preserve: accepted inputs, decisions, permissions and recorded results. A vendor can replace a canvas or a model. I still need to know what happened to the last task and whether retrying it will repeat an action.

What is closing, and what can move

Agent Builder is the hosted visual workflow product affected by this notice. ChatKit remains available. OpenAI’s ChatKit guide points new work and migration planning toward a custom server integration.

Date	Documented event
6 October 2025	Agent Builder launched in beta with AgentKit
3 June 2026	Deprecation announced
30 November 2026	Scheduled shutdown

The official migration guide describes copying the complete TypeScript or Python Agents SDK export from the Code dialog. It offers continuing in application code or recreating the workflow as a ChatGPT Workspace Agent. Export does not guarantee identical behavior.

For an application workflow, I would start with that export, then review control flow, tools, authentication and permissions in the destination runtime. Moving code out of a hosted product gives me something to inspect. It does not make the code independent of every SDK or API it calls.

The contract I keep outside the canvas

I want the model to propose a bounded result. Application code decides whether that result is valid and which action is permitted. The contract is small enough to review without opening the vendor’s editor.

Part	What I keep under application control
Input	Required fields, validation and the rule for rejecting incomplete work
State	Durable task status and the next permitted transition
Tools	Named capabilities with bounded arguments and permissions
Writes	Approval requirements and duplicate-action protection
Evidence	Recorded inputs, versions, decisions and execution receipts, within the allowed data boundary
Acceptance	Synthetic examples with expected outcomes and refusal cases

My coding-agent runner is one concrete example. It keeps task briefs and branch state outside the model provider. It also requires a fresh review file with a verdict. A provider change can interrupt a run, but it does not have to erase the task or redefine what counts as a completed handoff.

That is a pattern I can reuse. It is not evidence that I have migrated an Agent Builder installation, and I am not presenting one here.

A workflow on paper

Consider an invented document-processing example. A request arrives twice. The model extracts fields, one field is uncertain, and a person must approve the draft before anything is written. These are synthetic requirements, not a client result.

The sequence I would specify is:

1. Record an input reference and a stable task key.
2. Ask the model for a structured proposal.
3. Validate the proposal and preserve uncertainty.
4. Hold it for review when approval is required.
5. Execute the approved action with duplicate protection.
6. Record a receipt or a recoverable failure.

A replacement model may phrase its proposal differently. It must still respect the same transitions. I would reject a migration that turns an uncertain field into a confident value, bypasses review or executes the duplicate request twice.

Retries and fallback need a state record

Changing providers after a timeout is safe only when I know what the timed-out step could have done. For a read or a proposal, repeating work may be acceptable. For a write, a missing response leaves a harder question: did the action happen?

I put an idempotency key at the action boundary and reconcile an uncertain result before repeating it. I bound retries and record the last known state. A fallback model can suggest the next step; it does not get permission to widen the tool scope or repeat a write merely because the first provider failed.

This also limits portability. Provider-specific tools, session state and authentication can require new adapters. Moving a prompt is easier than proving equivalent side effects. I plan for that work rather than calling an export a completed migration.

My acceptance sheet for a replacement

Before giving a new runtime live write access, I would run the old and new paths against the same synthetic inputs. I would compare outcomes and recorded transitions, including deliberate failures.

• A valid request produces the expected proposal and state.
• A missing or uncertain field remains missing or uncertain.
• A duplicate input does not repeat the approved action.
• A timeout after an action leads to reconciliation, not a blind retry.
• Rejected approval prevents the write.
• An unavailable tool produces a recoverable failure with a clear next step.
• The replacement cannot call a capability the old contract forbids.

I would then move one bounded workflow, keep a rollback path and inspect its receipts. These are my proposed acceptance conditions. They are not promises that OpenAI’s export automatically implements them.

What I would prepare before 30 November

For an existing Agent Builder workflow, I would inventory its triggers, tools, prompts, state and permissions while access is still available. I would save the export, build the destination runtime and test the behavior there. Connected apps and authentication need separate review, as OpenAI’s migration guide makes clear.

The closure date is a reason to do that work now. My longer-term rule is to keep the automation’s contract somewhere I can version, inspect and run checks against. That gives me a way to assess a replacement even when the vendor’s original editor is gone.