OpenAI AgentKit: Agent Builder Shuts Down on 30 November 2026

Updated November 2026. OpenAI is shutting down Agent Builder, the visual canvas at the centre of AgentKit, on 30 November 2026. The Evals platform closes the same day. The Agents SDK and ChatKit stay. We have rewritten this guide around what is going, what is staying, and where to move what you built.

OpenAI AgentKit launched in October 2025 as a visual builder plus runtime for production agents. On 3 June 2026, OpenAI told developers it was deprecating Agent Builder. It shuts down on 30 November 2026, along with the workflows hosted in it.

So the question we get most often has changed. It used to be “should I use AgentKit or the Agents SDK”. Now it is “we built something in Agent Builder, so where does it go”.

We are Osher Digital, a Brisbane-based AI consultancy that ships agents into production for clients in healthcare, recruitment, and professional services. We have built agents on the Agents SDK, on Agent Builder’s drag-and-drop canvas, on LangGraph, and on raw API calls behind a FastAPI server. This is the migration guide we would want if we were starting the move today.

For background on the broader pattern, our piece on what an AI agent actually is covers the vocabulary. For an alternative implementation path, see our walkthrough of building an AI agent with Claude, which uses raw SDK code.

What is shutting down, and when

Part	Status	Date
Agent Builder (the visual canvas and its hosted workflows)	Shutting down	30 November 2026
Evals platform (dashboard and API)	Read-only now, then shutting down	Read-only from 31 October 2026, shuts down 30 November 2026
Reusable prompts (`v1/prompts`)	Shutting down	30 November 2026
ChatKit	Staying	No change
Agents SDK	Staying	No change

The dates come from OpenAI’s deprecations page. The Assistants API, which AgentKit was meant to replace, already shut down on 26 August 2026.

If you have anything running in Agent Builder, the hard deadline is 30 November. After that you cannot open the canvas to export it.

What AgentKit was

AgentKit bundled three things. A web-based visual builder called Agent Builder, where you dragged nodes onto a canvas to define an agent’s behaviour. A hosted runtime that ran those workflows and served them through ChatKit, OpenAI’s embeddable chat interface. And evaluation and tracing tools that recorded runs, scored outputs, and let you compare versions.

Underneath, the canvas generated the same primitives the OpenAI Agents SDK exposes in code: an agent definition, a list of tools, handoff rules between agents, and input and output guardrails.

That detail is what makes the shutdown manageable. Agent Builder was a visual editor and a hosted runtime on top of the Agents SDK, not a separate platform. The canvas goes away. The primitives do not.

Where your Agent Builder workflows can go

OpenAI’s migration guide gives two paths. We add a third, because some of these workflows were never a good fit for an agent platform in the first place.

Export to the Agents SDK

This is the path for anything your engineering team will own.

Open the workflow in Agent Builder.
Select Code in the top navigation.
Select Agents SDK.
Choose TypeScript or Python, then copy the complete export.

Treat the export as a first draft. OpenAI says plainly that it “does not convert your workflow graph or guarantee that every behavior transfers unchanged”. Branches, guardrails and tool settings all need checking. Our approach: export now, run the SDK version and the Agent Builder version side by side on the same inputs while both still work, and compare the outputs before you switch traffic.

You also need somewhere to run it. Agent Builder hosted the workflow for you. The SDK runs on your infrastructure, which for most agents means a small container behind your existing API.

Rebuild as a ChatGPT Workspace Agent

This is the path for agents a non-developer maintains and a team uses inside ChatGPT. It needs a ChatGPT Business, Enterprise or Edu workspace with access to workspace agents. You paste the export into a new workspace agent chat, review what the builder changes, and test it with real inputs before you publish.

Two cautions from OpenAI’s own guide. Workflows “with strong determinism at their core may not migrate faithfully”, because a workspace agent is built from natural-language instructions, not a fixed graph. And connected apps, authentication and permissions all need a separate review in ChatGPT.

Move it off OpenAI’s agent stack entirely

Some Agent Builder workflows were really integration pipelines with one LLM call in the middle. Those are better in n8n or Make, where the deterministic steps stay deterministic. We cover that boundary in our piece on building AI workflows in n8n. If the agent needs to mix model providers, LangGraph or a custom build is the cleaner home.

If you embedded the agent with ChatKit

ChatKit stays, but the setup most teams used does not. OpenAI’s recommended integration had OpenAI host the backend from an Agent Builder workflow. That backend goes on 30 November. The supported route is now what OpenAI calls the advanced integration: you run your own server with the ChatKit Python SDK, backed by an agent you built with the Agents SDK. The chat interface your users see can stay. What sits behind it moves to your server. Our piece on ChatKit widgets covers the front-end side.

If you used Evals

The Evals platform went read-only on 31 October 2026 and shuts down on 30 November. OpenAI points to Promptfoo as the replacement. Copy your test cases and grader definitions out now, while you can still read them. Do not let the evals lapse because the tool changed. An eval suite is what catches a model upgrade that quietly makes a downstream task worse.

What still holds

OpenAI’s hosted tools have not gone anywhere. Web search, file search and code interpreter run on OpenAI infrastructure and work from the Agents SDK and the Responses API. If you collapsed a search API, a Python sandbox and a vector store into AgentKit’s hosted tools, you keep that saving after the move.

The Agents SDK is open source and runs anywhere. That is now the main reason to choose it: nothing about it depends on a hosted product that can be withdrawn.

What the shutdown teaches

We used to warn clients that lock-in mattered more than the marketing implied. AgentKit’s hosted runtime was OpenAI infrastructure, so building there committed you to OpenAI for both the model and the orchestration layer. The shutdown is that risk arriving. Teams with workflows in code are changing nothing. Teams with workflows on the canvas have a deadline.

The canvas had other limits that make the move less painful than it sounds. It was clear for a single agent with five or six tools. By the time you had three agents handing off to each other, four guardrails and a branching router, the diagram was harder to read than the equivalent code. Version control on a visual workflow was fragile, because diffing two canvas snapshots is awful. We were already moving anything past a certain complexity from Agent Builder into Agents SDK code, where we can review pull requests like normal humans.

Our recommendation

The Agents SDK is the default for production agents. A custom build with raw SDK calls and your own orchestration is for agents with unusual requirements: multiple providers, on-premises hosting, unusual state machines, or anything where you need to debug the orchestration loop itself.

For the talent marketplace platform we built last year, we used the Agents SDK in TypeScript with about forty lines of glue around the loop and a Postgres-backed memory layer. The shutdown does not touch it.

The agents that lose most are the ones Agent Builder was best at. We built an internal “summarise overnight ticket activity” agent in Agent Builder for a healthcare client’s operations team. It has three tools and runs once a day, and its real value was that the operations lead could edit it without filing a developer ticket. Agents like that are the best fit for Workspace Agents, if the team has a ChatGPT Business or Enterprise workspace. If not, they move to the SDK, and someone technical owns the edits from then on.

A working example in the Agents SDK

Our reference example is a research-and-summarise agent. The user gives it a topic. The agent uses OpenAI’s hosted web search tool to find five recent articles, the file search tool to check whether the company has internal documents on the same topic, and a custom tool that posts a structured summary into a Slack channel. We first built it in Agent Builder in under an hour. In the Agents SDK it looks roughly like this:

from agents import Agent, Runner, WebSearchTool, FileSearchTool, function_tool
import httpx

@function_tool
def post_to_slack(channel: str, summary: str) -> str:
    """Post a research summary to a Slack channel."""
    httpx.post(
        "https://hooks.slack.com/services/...",
        json={"channel": channel, "text": summary},
        timeout=10,
    )
    return "posted"

research_agent = Agent(
    name="research_agent",
    model="gpt-6.1-sol",
    instructions=(
        "You research a topic, summarise five recent sources, "
        "check internal docs for context, and post the result to Slack."
    ),
    tools=[
        WebSearchTool(),
        FileSearchTool(vector_store_ids=["vs_internal_docs"]),
        post_to_slack,
    ],
)

result = Runner.run_sync(
    research_agent,
    "Summarise this week's developments in EU AI Act enforcement.",
)
print(result.final_output)

Same primitives, same tracing. The only thing you give up by writing it in code is the ability to hand a canvas to a non-developer, and after 30 November that option is gone anyway.

Things that broke for us in production

Three patterns we have hit and fixed. They apply whether the agent started on the canvas or in code.

Tool descriptions matter more than the docs imply. Two agents we built had subtle accuracy regressions when we shortened a tool description from a paragraph to a sentence. The model uses the description to decide when to call the tool, and a vague description is worse than no description. Our rule now: every tool gets a description that includes a one-line purpose, the input shape, and at least one example of when to use it. Check these after an export, because they are easy to lose.

Long-running tool calls need designing for. Agent Builder’s hosted runtime had timeout behaviour that was reasonable for synchronous agents and harsh for any tool that took more than thirty seconds. We had a workflow that called a third-party enrichment API which sometimes took ninety seconds, and the agent looked like it was hanging. The fix was to break the long call into a queued background job and have the agent poll for the result. On your own infrastructure you control the timeouts, but the same design is still the right one.

Cost runaway is real if you let agents loop without bounds. Set a maximum step count on every agent. We default to twelve. An agent that genuinely needs more than twelve steps almost always has a tool design problem, not a step-count problem.

When OpenAI’s agent stack is not the right choice

Skip it if you need to mix providers. We use Claude for most extraction work because it is materially better at structured outputs over messy real-world documents. The Agents SDK has community-maintained adapters for other providers, but support is uneven.

Skip OpenAI-hosted orchestration if your agent has to run inside your own VPC. Healthcare clients with My Health Record data, regulated finance work under APRA CPS 234, and anyone with a data residency requirement that names ap-southeast-2 will need to host the orchestration themselves. The Agents SDK can do that; Agent Builder never could.

Skip it if your agent is really an integration workflow with one LLM step in the middle. n8n or Make is the right tool there.

Cost and pricing notes

Agent Builder was included in your OpenAI usage, and so is the Agents SDK. You pay for model tokens, hosted tool calls (web search, file search and code interpreter each have their own per-call pricing), and any storage you use for vector stores or files.

Moving to the SDK adds one line item: somewhere to run it. For most agents that is a small container on infrastructure you already pay for.

For a typical small-to-medium agent doing a few hundred runs per day, expect monthly costs in the $80 to $400 USD range, which is roughly $120 to $620 AUD. The hosted tools are the expensive bit. A web search call costs materially more than the model call that triggered it. We cache search results aggressively for any agent that runs more than a few times a day.

If your agent volume is high enough that costs become a real line item, multi-provider routing through the Agents SDK or a custom build is worth the extra engineering work. We have moved a couple of clients off pure OpenAI for the routing parts of their pipeline and saved 30 to 60 percent on that portion of their bill.

Getting started without overbuilding

If you are starting fresh, the advice has not changed: build the smallest possible agent that does one useful thing. Not three things. One. Ship it. Use it for two weeks. Then add the next capability.

What you need to begin: an OpenAI account with API access, somewhere to run the code, and a clear bounded problem. The bounded problem is the part most people get wrong. “An agent that handles customer support” is not bounded. “An agent that drafts a reply to refund-request emails for review by a human” is bounded. Start there.

If you have Agent Builder workflows to move before 30 November and want a hand, book a call and we will work through them with you.

Frequently Asked Questions

Is OpenAI AgentKit being discontinued?

In part. OpenAI is shutting down Agent Builder, the visual canvas, and the Evals platform on 30 November 2026. The Agents SDK and ChatKit stay. OpenAI announced the change on 3 June 2026.

What happens to my Agent Builder workflows after 30 November 2026?

Agent Builder and the workflows hosted in it will no longer be available. Export each workflow as Agents SDK code before then. Once the canvas is gone, you cannot export from it.

How do I export a workflow from Agent Builder?

Open the workflow, select Code in the top navigation, select Agents SDK, choose TypeScript or Python, and copy the complete export. The export is a starting point, not a finished migration. Test it against the original before you switch over.

Should I move to the Agents SDK or to ChatGPT Workspace Agents?

The Agents SDK if developers will own the agent, it runs inside your product, or it needs to behave the same way every time. Workspace Agents if a team uses it inside ChatGPT and a non-developer needs to edit it. Workspace Agents need a ChatGPT Business, Enterprise or Edu plan.

Does ChatKit still work?

Yes. ChatKit itself stays. The integration where OpenAI hosted the backend from an Agent Builder workflow does not. Move to the advanced integration, where your own server runs the ChatKit Python SDK with an Agents SDK agent behind it.

Is the Agents SDK open source?

Yes. It is on GitHub under the openai organisation, in Python and TypeScript, and it runs on your own infrastructure. It is the part of AgentKit that does not depend on a hosted product.

What replaced the Assistants API?

The Assistants API shut down on 26 August 2026. OpenAI’s replacement is the Responses API with the Conversations API. The Agents SDK sits on top of the Responses API and is the simpler starting point for anything agent-shaped.

Can the Agents SDK use models other than OpenAI’s?

The SDK has community-maintained adapters for other providers, but support is uneven and we would not bet a production system on it. If you need multi-provider routing, use a custom build or a provider-neutral framework such as LangGraph.

Does this work for organisations with Australian data residency requirements?

Partly. OpenAI can now store API data at rest in Australia for approved customers, but model calls are still processed outside the country. With the Agents SDK you host the orchestration yourself, in ap-southeast-2 if you need to, and call OpenAI models from there. For genuinely sensitive data (My Health Record, APRA-regulated workloads), that may not be enough, because the model calls still leave Australia.

What does running an agent on the Agents SDK cost?

You pay for model tokens, hosted tool calls and storage, plus your own hosting. For a small agent running a few hundred times a day, that lands in the $80 to $400 USD per month range (roughly $120 to $620 AUD). Agents that use web search heavily will run higher. Set a step limit and a daily spend cap before you go to production.

Where to from here

Agent Builder made agents quick to prototype and easy for non-developers to edit. It also tied them to a hosted product, and that product is closing. If you have workflows on the canvas, export them this month, test the exports against the originals, and pick a home for each one based on who will maintain it.

If you want help deciding which agents to move, which to rebuild and which to retire, get in touch. We have built enough of these to know which ones earn their keep.