Deprecation notice: Agent Builder

API Deprecations
1

This can’t be true??? The Agent Builder was only released around November last year (2025) and is now being deprecated!

I use the managed agent builder with Chatkit UI, for multiple clients, and migrating to manage the backend myself, makes the use of this tool economically unviable.

Please confirm that this deprecation means that the ChatKit recommended implementation is also not available.

I trust that OpenAI will revise this decision and continue with the Agent Builder and recommended approach for Chatkit implementations.

There are two ways to implement ChatKit:

  • Recommended integration. Embed ChatKit in your frontend, customize its look and feel, let OpenAI host and scale the backend from Agent Builder. Requires a development server.
  • Advanced integration. Run ChatKit on your own infrastructure. Use the ChatKit Python SDK and connect to any agentic backend. Use widgets to build the frontend.

Screenshot 2026-06-04 at 14.20.18
Screenshot 2026-06-04 at 14.20.18577×460 40.2 KB

2

Unfortunately, this was clearly coming, as there wasn’t much support right after it was launched.

It would be nice if OpenAI open-sourced Agent Builder / ChatKit Studio, so at least people who started projects with it could keep them going. It might also give a third party the opportunity to provide infrastructure support for it.

I would also see open-sourcing these tools as a way to potentially make the Agents SDK stronger, since what it currently lacks is a UI to make agents more practical for people who don’t want to build the entire IT architecture for agents from scratch.

Hopefully, someone from the staff sees this and takes it into consideration.

3

Yes, in hindsight It seems obvious that this was going to be deprecated. Though I have invested many hours in this technology, believing that it was a long term tool and OpenAI’s response (excuse the pun) to n8n and make.com, etc…

Maybe OpenAI needs to deprecate a few of their product mánagers or leadership. Building and oferring a tool that in around 6 months is deprecated…??? Not a sound business strategy to me.

4

Ive just migrated from the Agent Builder backend to my own custom server for hosting the Chatkit backend, using Fast API. Does anyone know where I can host and deploy this server, given my requirement of minimal costs? (I was currently evaluating AWS LightSail, Render, Fly io, etc…).

"Custom server integration. Run ChatKit on your own infrastructure."

5

I put together a small “.intake” starter package for anyone looking at migrating an existing Agent Builder-style implementation to Cloudflare Workers/Agents.

The idea is simple: place your current code and other files inside “.intake/source/”, keep the provided “start.md” as the Codex entry prompt, then ask Codex to research the existing implementation, research the current Cloudflare infrastructure options, propose the best migration architecture, scaffold the repo, and generate a “kickoff.md” execution plan.

It also recommends using Cloudflare’s Codex plugin or MCP server so Codex can work against current Cloudflare docs and tooling.

ZIP attached. Hope it helps others exploring a low-cost migration path before Agent Builder shutdown.

Important Note: prefer typescript export for cloudflare.

WARNING: NOT TESTED, NO WARRANTY, USE AT YOUR OWN RISK, REPORT ISSUES TO SERGE LIATKO HERE IN FORUM

6

Great share, @sergeliatko.

Do you think it would make sense to turn this into a community project with a public repo?

7

Definitely, will be great. I’m out with kids tonight (zip from cell phone), but I’ll push that tonight after making a basic agent for testing.

8

If anyone has typescript export or 2 with agents from there for tests, that would speed up the public repo

9

@che.kulhan To answer your direct question: ChatKit itself survives, but the “Recommended integration” you quoted is effectively dead, that path depends on OpenAI hosting the backend from Agent Builder, and Agent Builder shuts down Nov 30. What remains is the “Advanced integration”: ChatKit frontend + your own backend via the ChatKit Python SDK and the Agents SDK.

For a multi-client setup, the economics aren’t as bad as they first look: the backend is the same code for every client, with per-client config (instructions, tools, knowledge) stored as data. You build the loop once, not N times. The real one-way door is timing, exports of existing workflows are only possible while the dashboard is still up.

One trap to avoid while migrating: don’t move workflow prompts into dashboard Prompt Objects, those are also being shut down Nov 30 (see the parallel deprecation notice). Keep config in your own code/DB or you’ll migrate twice.

10

Agent Builder is a great product and service. Here to hoping that they bring it back

11

Has anyone have gotten the chat server working on AWS?

12

I ended up building a fast API Server, and deploying it on IBM, the lowest cost I could find. I tried Oracle, but the VM (virtual machines) never became available. Ive still got a few issues to sort out with cold starts, but I think it is feasible.

As an AWS customer, I couldnt find a cost effective way to deploy the server.

13

Have you tried cloudflare workers?

14

Got it working on with AWS Lambda Web Adapter.

Agent Builder was much easier. I am already missing it.

15

@Michael_Giraldo What are the cold starts like (i.e on the first call, does it take 10 or 20 seconds to start up)?

Could you expand on the tech stack you used (i.e flask, fast API, etc)?

Im interested in comparing it to the IBM VM I deployed with fast API, to evaluate speed and costs.

17

I ran the safe cold-start probe against production /chatkit/health.

**Current Deployed Lambda (**Lambda Web Adapter)

Function: CustomChatkitLambda
Last modified: 2026-06-22 12:54:46 PDT
Package type: Image
Runtime: container-owned, not managed Lambda runtime
Memory: 1024 MB
Timeout: 60s
Architecture: x86_64

Latest Cold-Start Probe
I ran 20 concurrent health requests at 2026-06-23 07:25 PDT.

Result:

20 / 20 returned HTTP 200
fastest total time: ~2.84s
slowest total time: ~3.69s

CloudWatch showed 20 fresh cold starts:

cold starts: 20
min Init Duration:  2521.72 ms
avg Init Duration:  3143.77 ms
p50 Init Duration:  3203.16 ms
p95 Init Duration:  3317.19 ms
max Init Duration:  3374.12 ms
latest cold start:  2026-06-23 07:25:38 PDT

So the latest package is cold-starting around 2.5s to 3.4s for health requests.

The stack is Python 3.14 + FastAPI + Uvicorn running in a Lambda container image behind Lambda Web Adapter, with OpenAI ChatKit/Agents SDK and DynamoDB. We still need a like-for-like benchmark against the IBM VM for first real chat response, streaming behavior, and cost.

Two different measurements from two different places.

curl total time     = what the outside caller experienced
Lambda Init Duration = what AWS says Lambda spent initializing the runtime

In our run:

fastest curl total time:        ~2.84s
fastest Lambda Init Duration:   ~2.52s

So 2.84s is not slower/contradicting 2.52s. It includes more than Lambda init.

2.84s curl total
-2.52s Lambda init
=~0.32s API Gateway/network/adapter/app overhead

What are the IBM VM benchmarks?

18

Not as detailed as yours @Michael_Giraldo , but I got the cold starts down from 30 seconds to just under 20. Still way too long.

So effectively your lambda solution is viable, and IBM isnt (without having the VM running continuously which would cost 15 to 30 USD a month.)

Im using a similar tech stack to you so I’ll migrate It to Lambda and its adapter. Thanks a million @Michael_Giraldo !

19

You’re welcome @che.kulhan

20

Love to see this! Hope you two stick around. We’ve got a great community growing, and we’d love to have people like you!

21

Another issue. There’s an important finding: openai-guardrails==0.2.1 does not currently install cleanly under Python 3.14 because one of its dependencies has <3.14 bounds.