What should Agent Builder users do now that it's winding down?

On June 3, OpenAI added a short update to its AgentKit announcement: it is winding down Agent Builder, the visual canvas for designing agents, and Evals, its hosted tool for testing them. From November 30, 2026, neither will be available on the OpenAI platform. OpenAI points two ways forward. For workflows that should keep running as code, it recommends the Agents SDK, its Python library for building agents. For jobs that are better handled by plain-language instructions, it recommends Workspace Agents in ChatGPT.

There is no need to panic, but there is a deadline. An agent that works today will keep working until the end of November, which gives you time to move it calmly, test the new version side by side with the old one, and switch over only when the results match.

First, decide where each agent should go

Start with a list of every agent you built on the canvas, then sort them with one question: does this agent need to run inside other software, or does a person start it by asking for something?

Second, write down what the canvas does

Before you change anything, capture the current agent while you can still open it. A canvas hides decisions inside boxes, and you will need them in writing. For each node, which is a box that does one job, record:

1. Instructions: copy the full text, not a summary.
2. Model and settings: which model, and any reasoning or output options.
3. Tools: web search, file search, connectors, or your own functions.
4. Branches: the conditions that send a request one way or another.
5. Guardrails: the checks that block or mask certain inputs or outputs.
6. Test cases: ten to twenty real requests with the answer you expect for each, including the awkward ones.

That last list matters most. It is what tells you, later, whether the rebuilt agent behaves like the old one.

Third, replace hosted Evals with your own script

An eval is a repeatable test: a set of inputs, the result each one should produce, and a way to score the output. You do not need a hosted service for that. A small script and a spreadsheet saved as CSV are enough to start. The example below assumes a support agent that sorts customer emails into categories. The file cases.csv has two columns, email and expected.

import csv
from pydantic import BaseModel
from agents import Agent, Runner

class Triage(BaseModel):
    category: str      # "billing", "technical" or "other"
    reason: str

triage = Agent(
    name="Triage",
    instructions=("Read the customer email. Choose one category: billing, "
                  "technical or other. Give a one-sentence reason."),
    output_type=Triage)

passed, failures = 0, []
with open("cases.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        result = Runner.run_sync(triage, row["email"]).final_output
        if result.category == row["expected"]:
            passed += 1
        else:
            failures.append((row["email"][:60], row["expected"], result.category))

print(f"{passed} passed, {len(failures)} failed")
for email, want, got in failures:
    print(f"- expected {want}, got {got}: {email}...")

Two features of the SDK make this work. The output_type setting makes the agent return fixed fields that code can compare, instead of free text. And Runner.run_sync runs one request and hands back the result in final_output. Run the same cases against the old canvas agent and the new code agent, and compare the two scores.

How do you move an agent to code?

Rebuild one node at a time. Each agent node on the canvas becomes one Agent in Python, with the same instructions pasted in and the same tools attached. The SDK README describes the basics: install it with pip install openai-agents, set your OPENAI_API_KEY environment variable, create an agent with a name and instructions, and run it with Runner. Your own Python functions become tools with the @function_tool decorator.

Then rebuild the arrows between nodes. The SDK documentation describes two styles. In code orchestration, your program calls agents in a fixed order and checks each result, which is the closest match to a canvas with clear branches. In model orchestration, one agent decides which specialist to call or hands the conversation to another agent; handoffs are the SDK's term for that. The documentation notes that orchestrating in code is more predictable in speed, cost and performance, so it is the safer first choice when you are copying an existing design.

A canvas branch such as "if the category is billing, send to the billing agent" becomes an ordinary if statement:

first = Runner.run_sync(triage, email).final_output
if first.category == "billing":
    reply = Runner.run_sync(billing_agent, email).final_output
else:
    reply = Runner.run_sync(general_agent, email).final_output

Finally, run both versions in parallel for a while. Send the same real requests to the canvas agent and the code agent, keep the old one live, and switch only when your eval script shows the new version passing at least as many cases. Keep the CSV file and the script in the same folder as the agent's code: they are now your Evals, and they will still work long after November 30.