By Greg Nowak. Last updated 2026-07-10.
OpenAI has set an end date for Agent Builder. From November 30, 2026, the visual workflow product will no longer be available on the OpenAI platform.
That does not mean every part of AgentKit is disappearing. But if your business relies on the canvas for an active workflow, you now have a migration project, even if nobody has put it on the delivery plan yet.
Copying the prompts is not enough. A working agent also depends on routes, tool definitions, guardrails, state, approvals, failure handling and tests. Save those behaviours and you have a specification you can rebuild from. Save only the text boxes and you may find yourself reverse-engineering your own system as the deadline approaches.
What OpenAI has announced
OpenAI’s updated AgentKit announcement says Agent Builder and Evals are being wound down and will leave the platform on November 30, 2026. OpenAI recommends the Agents SDK for workflows that should continue as code. For work better handled through natural-language prompting, it points teams towards Workspace Agents in ChatGPT.
The difference is practical. Agent Builder gave teams a visual canvas for connecting logic, tools, custom guardrails, previews, inline evals and versions. Its retirement removes the place where those decisions are currently expressed; it does not require every surrounding component to be replaced.
The independent migration guide distinguishes Agent Builder and hosted Evals from components that remain, including ChatKit. It also notes that MCP-based tool connections can move into another runtime. Before rebuilding anything, establish exactly which parts of your current setup are affected.
Treat the current workflow as a specification
Begin with an inventory. List each workflow, its owner, version, environment and consumers. Separate short-lived experiments from internal utilities and customer-facing dependencies. This prevents an abandoned prototype from receiving the same attention as a workflow tied to a live operational process.
For each active workflow, document enough detail that a developer could reconstruct its behaviour without access to the canvas.
| Workflow asset | What needs to be captured | How to test the replacement |
|---|---|---|
| Instructions | System instructions, task prompts, templates and variables | Use representative inputs and define the expected qualities of a good response |
| Routing | Branches, conditions, handoffs, stop rules and iteration limits | Create at least one test for every important path |
| Tools | Names, schemas, authentication dependencies, timeouts and error behaviour | Test valid, invalid and failed calls against the tool contract |
| Controls | Input and output guardrails, approvals and escalation points | Include cases that should pass, be blocked or be handed to a person |
| State | Conversation history, session boundaries and retained context | Test multi-step, resumed and expired sessions |
| Evaluation | Datasets, graders, known failures and accepted baselines | Run the same fixtures against the current and replacement workflows |
Look beyond the canvas as well. Record which application calls the workflow, who responds when it escalates, and which systems sit behind its tools. These dependencies are easy to overlook because they are not visible as nodes.
If you use hosted Evals, the migration guide identifies October 31, 2026 as the date when existing evals become read-only. In practice, that should be treated as the deadline for exporting evaluation assets. Waiting until the November shutdown leaves very little room to discover that an important fixture or grader was missed.
Choose a destination for each workflow
There is no need to push every prototype into one replacement architecture. OpenAI names two broad directions, and the sensible choice depends on who operates the workflow and how deeply it connects to other business systems.
- Workspace Agents may suit simpler internal work led by prompting. Consider this route when a knowledgeable employee can describe and supervise the task in natural language, and there is no need to run it as a bespoke production service.
- The Agents SDK suits workflows owned as software. It is the stronger fit when an agent sits inside a website, product or operational process; calls tools through defined contracts; maintains controlled state; or needs engineering-owned testing, tracing, deployment and rollback.
- Some workflows should not be migrated. A prototype with no owner, users or measurable purpose does not automatically deserve a production rebuild. The deadline is a useful opportunity to remove work that no longer earns its maintenance cost.
Make this decision workflow by workflow. The same company might reasonably use Workspace Agents for a low-risk internal assistant and the SDK for a customer-facing process.
Rebuild the orchestration, not the picture of it
The official JavaScript and TypeScript Agents SDK repository provides many of the code-level building blocks a migration may require: agents, tools, handoffs, guardrails, human involvement, sessions and tracing. These are useful destinations for the logic currently represented by canvas nodes, but migration is not a matter of transcribing boxes into code.
Once the workflow becomes application code, someone must own configuration, errors, secrets, releases and observability. Those responsibilities existed before; the canvas simply kept some of them out of view.
An official Node SDK cookbook example shows the division of responsibility clearly. OpenAI can indicate which function should be called, but the application invokes that function, returns its result to the model and controls the loop. Tool execution is application behaviour. It cannot be preserved inside a prompt.
Define each tool as an interface. Validate its arguments. Separate failures that can be retried from those that cannot, limit repeated calls, and decide what the user should see when a dependency is unavailable. Give each branch and handoff an explicit home in the code, and be deliberate about when sessions begin, resume and expire.
Built-in tracing can help inspect individual runs. Operational logs and alerts still need to match the surrounding application, particularly where a technically successful run can produce a business failure.
Test behaviour before changing the entry point
An agent can return a plausible answer and still be operationally wrong. It might call the wrong tool, omit an approval, lose earlier context or continue after a stop condition. Migration testing therefore needs to cover routes and side effects, not just the final wording.
Build a compact fixture set from real examples that can be handled appropriately, together with known edge cases. Include ordinary requests, ambiguous input, tool failures, blocked content, human escalation and multi-turn state. Run the fixtures against the current workflow to establish a baseline, then repeat them against the replacement.
Exact text matching is rarely useful for non-deterministic output. Test the properties that matter instead: which route was selected, which arguments were sent to a tool, whether the right control fired, and whether the outcome met the required quality bar.
Cut over gradually. Start in a test environment. Where policy and data handling allow it, shadow or replay traffic. Release to a limited group, inspect traces and watch for failures at the business level before moving the main entry point.
Keep the previous path, or another safe fallback, available until the replacement has completed an agreed observation period. Rollback conditions should be written down before launch, when the team can still discuss them calmly.
Use the deadline to make the workflow easier to own
For teams without spare delivery capacity, this can be handled as a focused discovery and implementation engagement. Greg can help inventory active Agent Builder and Evals assets, document their dependencies, choose an appropriate destination, and rebuild code-owned workflows with the JavaScript/TypeScript or Python Agents SDK.
The work can also cover tool-contract tests, evaluation fixtures, tracing, deployment automation, staged cutover and rollback planning. The aim is to leave clear ownership and operating instructions behind, rather than create another opaque system that depends on one person remembering how it works.
Meeting the November 30 deadline matters. The more valuable outcome is a workflow your business can inspect, test and change when a model, tool or business rule changes.
Related on GrN.dk
- Background AI Tasks Need Queues, Not Just Longer API Calls
- OpenAI Evals Bring Acceptance Tests to AI Workflow Releases
- OpenAI's Guardrails and Run State Make Internal Agent Rollouts a Paid Approval-and-Audit Job
Need help with this kind of work?
Plan your Agent Builder migration Get in touch with Greg.