Somewhere in your business there may be a small piece of automation that nobody in IT has heard of.
Someone in marketing or operations built it in an afternoon on a visual builder, because it was quick and did not need a budget request or a ticket. It drafts the replies, or tags the enquiries, or writes the weekly summary that appears in a channel. It has worked ever since. It is now part of how a process runs, and nobody wrote that down.
On 30 Nov 2026, the tool it was built in closes.
That is the whole problem in one sentence, and the technical part of it is the easy half. The hard half is that the thing which made these agents cheap to build, no oversight required, is the same reason nobody can tell you how many you have.
The dates are published and only one of them stops a working agent
OpenAI announced the wind-down on 03 Jun 2026. Checked against OpenAI's own deprecations page on 08 Aug 2026:
| Date | What happens | What it means for a working agent |
|---|---|---|
| 31 Oct 2026 | Existing evals become read-only | Any record of whether the agent performs well freezes here |
| 30 Nov 2026 | Agent Builder shuts down | Anything built in it stops |
| 30 Nov 2026 | The Evals dashboard and API shut down | |
| 30 Nov 2026 | Reusable prompt objects and the v1/prompts API shut down | Instructions stored in the dashboard rather than in your own files go with them |
| Not affected | ChatKit remains available | See the next section, because this one catches people out |
Two of these are worth translating out of developer language.
The evals date matters because measurement dies a month before the thing it measures. If anyone set up a way of checking that the agent produces sensible output, that evidence stops being editable on 31 Oct 2026 and disappears on 30 Nov 2026. If you want a record of what "working" looked like, take a copy while you can.
The prompts date matters because the instructions given to these agents are often the only real intellectual property in them. Somebody spent a fortnight refining the wording that makes the output usable. If that wording lives in a dashboard object rather than a file your company holds, it goes when the dashboard goes. Copying it somewhere you own costs ten minutes and is worth doing before anything else on this list.
ChatKit surviving does not mean your chat widget survives
This is the single easiest thing to get wrong here, and it is a branding accident.
OpenAI's deprecations page says, of Agent Builder, that "ChatKit remains available". ChatKit is not part of the wind-down. Reading quickly, that sounds reassuring: the customer-facing chat component is safe.
It is safe, and that may not help you. ChatKit is the front end, the box the conversation appears in. Where a workflow was built in Agent Builder and then surfaced through ChatKit, the interface points at that workflow by its ID. The interface survives 30 Nov 2026. The workflow it points at does not.
So the failure to plan for is not the widget vanishing from your website. It is the widget still sitting there, still branded, still inviting customers to type into it, with nothing behind it. That is the worse outcome, and it is the one a casual reading of the announcement talks you out of worrying about. If anything customer-facing was built this way, that alone justifies establishing where you stand now rather than in November.
Finding out whether you have one is a people problem, not a technical one
There is no scan you can run for this. The whole point of the tool was that it left no trace in your codebase, because there was no codebase. Five things actually work, in the order that gets you an answer fastest.
Follow the money. An OpenAI platform account bills separately from ChatGPT seat subscriptions, so ask finance to search the card statements and expenses system for a usage-based charge rather than a per-seat one. This is usually the fastest route to a yes, and it tells you the second thing you need to know: whose name the account is in.
Get someone into the account and look. Agent Builder lists what has been built in it, so somebody with admin rights can produce a list in a few minutes. If nobody currently employed has admin rights, stop and fix that first. You have found a larger problem than the deadline.
Ask by symptom, not by product name. "Has anyone built an AI agent?" reliably returns no, partly because people do not think of what they made as an agent, and partly because the question sounds like the opening of a disciplinary process. Ask instead: is there anything you set up that now does a job for you automatically, that you would have to start doing by hand if it stopped? Say plainly that the answer will not get anyone in trouble, and mean it. You need the information more than you need the point.
Look for the outputs. Work that appears without anyone doing it is the reliable tell. Draft responses waiting in a queue each morning, enquiries already categorised, a summary posted to the same channel at the same time, records updated overnight. Trace one back and you find the builder.
Check what the leavers left. Anyone who changed teams or left since early 2025 is worth a specific thought, because their automation is the most likely to still be running and the least likely to be understood.
One outcome deserves naming. If the agent was built on a personal account with a personal card, you may have no visibility and no control at all, and no way to take it over. That is not a wind-down problem, it is a governance one, and it would have surfaced eventually. This is the cheap moment to find it. If you want the broader version of this exercise across everything unofficial that has crept into your stack, we set it out in our shadow AI audit.
Three options, and switching it off is a real answer
Assume you find one. There are three defensible things to do, and the industry commentary on this almost universally assumes the first.
| Option | Choose it when | The honest catch |
|---|---|---|
| Rebuild on the supported stack | It touches customer data, money or a system of record, or it runs often enough that no one can absorb the work by hand | Real engineering, priced accordingly. The date is fixed for everyone, so the queue for this work fills up towards the end |
| Replace it with configuration in something you already pay for | The job has a recognisable shape: drafting, summarising, routing, categorising, updating records | You inherit the vendor's limits. Check it does the whole job, not the demonstrable eighty per cent, before you commit |
| Switch it off | Nobody can say what breaks on 01 Dec 2026 | Somebody will be annoyed on 02 Dec. Establish who uses it before you turn it off, not after |
For the rebuild route, OpenAI names two destinations: the Agents SDK for workflows that should continue as code, and ChatGPT Workspace Agents where natural-language prompting suits the use case. Agent Builder also has a Code option in its top navigation that will produce Agents SDK code from an existing workflow, which is useful as a starting point and as documentation of what the thing currently does. Treat it as a starting point rather than a migration, because exported code still has to be hosted, monitored and owned by someone.
For the replacement route, the point most often missed is that you may already be paying for the answer. A great many of these agents do CRM-shaped work: summarise this, draft that, route the other, keep a field up to date. If that describes yours, configuration inside the CRM is usually cheaper, better governed and better connected to your data than anything rebuilt alongside it, and HubSpot's own AI capabilities cover a reasonable share of it. Establish this before commissioning a rebuild, not after.
The four questions that actually decide it
- What does it touch? Customer data, money, or a system of record puts it in the rebuild-or-replace-properly category and takes "quietly recreate it somewhere else" off the table.
- How often does it run, and what does the alternative cost? Something that runs twice a month is work a person can do. Something that runs two hundred times a day is not. This is arithmetic, and it settles more of these arguments than any discussion of capability.
- Can you name what breaks on 01 Dec 2026? If nobody can, you have your answer, and it is free. A forced deadline is an unusually good moment to ask what a thing returns, because it is the one moment when doing nothing has a price attached.
- Does the output have to match exactly, or approximately? "Keep doing roughly this" and "the output must match, because something downstream depends on it" are different jobs at different prices. Decide which you are buying before anyone quotes for it.
If you have both a no-code agent and something a developer built on the Assistants API, they are separate problems on separate dates, and we have written the other one up as the Assistants API retirement.
Next time, record it rather than ban it
The instinct after an episode like this is to prohibit building without approval. It is the wrong lesson and it does not work. The person who built the agent solved a real problem in an afternoon for no money, which is the behaviour a business should want. Ban it and you lose that without stopping the behaviour: you move it somewhere you cannot see, which is where it was already.
What failed was not the building. It was that nothing recorded what had been built. Three things fix that, and none of them require a committee.
A register, one row per agent. What it does, who owns it, what systems and data it touches, roughly what it costs to run, what breaks if it stops, and the date it was last looked at. A single shared table is enough. The value is not in the detail, it is in the existence of a list.
A named person per agent, not a team. Teams do not notice deprecation notices. People do. The owner does not have to be technical. They have to be the person who gets asked when it breaks.
One review rule, narrowly drawn. Anything that reads customer data, writes into a system of record, or touches money gets looked at before it goes live. Everything else can be built freely. Narrow the rule to the things that can genuinely hurt you and people will follow it, because it is honest about where the risk sits. Make it apply to everything and it gets ignored, which returns you here.
The trade being offered is a fair one. The business says yes quickly to low-risk automation, and in exchange it gets to know the automation exists. That is the arrangement that would have made 30 Nov 2026 a scheduled task rather than an investigation.
The decision in front of you
Work out whether you have any. For most businesses the answer will be no, and the certainty is worth the morning it takes.
If the answer is yes, decide deliberately, and soon, between rebuilding it, replacing it with configuration you already own, and switching it off. All three are respectable. What is not respectable is arriving at 30 Nov 2026 having made the decision by default, or discovering on 01 Dec 2026 that a chat box on your website has been talking to customers with nothing behind it.
The wider comparison, including the options either side of this one, is in our guide to what OpenAI offers a UK business.
We are an OpenAI Select Partner and we do this work, but we would rather you knew where you stood than bought something. If you want the exposure established and priced, request a quote and tell us what you think is running, or what you suspect might be. We take no margin on your usage and we resell nothing, so if the right answer is that your existing CRM already does it, or that the thing should simply be turned off, that is what we will tell you.
Stay Updated with Our Latest Insights
Get expert HubSpot tips and integration strategies delivered to your inbox.
