# Agent Builder is shutting down: a portable Node-RED migration checklist

**URL:** <https://discourse.nodered.org/t/agent-builder-is-shutting-down-a-portable-node-red-migration-checklist/102044>\
**Category:** General\
**Created:** [2 November 2026 12:12 UTC](https://discourse.nodered.org/t/agent-builder-is-shutting-down-a-portable-node-red-migration-checklist/102044 "2026-11-02T12:12:01Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![vitayao](https://avatars.discourse-cdn.com/v4/letter/v/50afbb/32.png) [@vitayao](https://discourse.nodered.org/u/vitayao)\
**Post date:** [2 November 2026 12:12 UTC](https://discourse.nodered.org/t/agent-builder-is-shutting-down-a-portable-node-red-migration-checklist/102044/1 "2026-11-02T12:12:01Z")

</div>

OpenAI's Agent Builder is scheduled to shut down on November 30, 2026. If a production workflow still depends on it, I would avoid a direct screenshot-for-screenshot rebuild. The safer migration target is the workflow's behavior: inputs, decisions, tool calls, state, approvals, retries, and outputs.

The date and migration notice are in OpenAI's official Agent Builder documentation.

Here is a Node-RED migration checklist that keeps those behaviors explicit.

## 1. Convert the canvas into contracts

For every Agent Builder node, write down:

- accepted input schema
- output schema
- side effects
- retry policy
- timeout
- whether a human approval is required

This catches hidden assumptions before the old builder disappears.

## 2. Map responsibilities to subflows

A practical Node-RED shape is:

`HTTP In -> Normalize -> Router -> Tool subflow -> Verify -> Approval gate -> HTTP Response`

Keep each tool in its own subflow. The router should choose a capability, not embed credentials or business logic.

## 3. Add state that survives restarts

Store at least:

- `correlationId`
- `idempotencyKey`
- current step
- tool receipt or external reference
- retry count
- approval status
- last error class

A larger context window is not a substitute for resumable state.

## 4. Separate failure classes

Use separate branches for:

- transport or HTTP failure
- invalid JSON/schema
- model refusal
- tool failure
- review candidate

Do not send all five into the same generic retry loop. Retries should have a budget, and exhausted items should go to a dead-letter flow.

## 5. Move secrets out of the flow export

Use Node-RED credentials or environment variables. A portable flow should export topology and configuration names, not API keys.

## 6. Test with fixtures before cutover

Create a small set of saved inputs for:

- normal request
- duplicate request
- delayed tool
- malformed model output
- approval denied
- restart during a tool call

Compare semantic outcomes, not wording.

## 7. Make model choice replaceable

Keep the provider adapter behind one subflow so the workflow does not change when a model changes. A unified API layer such as Tokatlas can be used to compare candidate models without rewriting the rest of the flow.

The useful migration artifact is not a copied canvas. It is a documented, testable set of contracts that can run after any one vendor UI is gone.

For people already migrating: which part is proving hardest to reproduce in Node-RED—state, tool calling, approvals, or evaluation?