Skip to content
All articles

Sep 10, 2026 · 3 min read

Agent tooling has a short life: don't put business logic there

OpenAI shipped Agent Builder in November 2025, announced its retirement in June 2026 and shuts it down at the end of November. Custom GPTs are being replaced too. The lesson is about where business logic lives.

On 4 June 2026 OpenAI posted a deprecation notice for Agent Builder, with a shutdown date of 30 November 2026. The tool launched in November 2025. Its lifespan was roughly six months.

This is not an isolated incident, and not a reason to criticise OpenAI. It is a characteristic of this whole category right now, and something to account for when choosing an architecture.

What happened

The notice points users towards deeper integration instead: ChatKit on the front end combined with your own backend through the ChatKit Python SDK and the Agents SDK. In other words, run your own infrastructure rather than rely on a packaged builder. In the discussion thread, users also found that Prompt Objects shut down on the same date.

In parallel, on 22 April 2026 OpenAI introduced Workspace Agents, positioned explicitly as the successor to Custom GPTs, connecting to Slack, Google Drive, Microsoft apps, Salesforce, Notion and Atlassian Rovo. According to VentureBeat's reporting, the company said it would retire the Custom GPT standard for organisations at an unannounced future date, and that Workspace Agents were free until 6 May 2026 before moving to credit-based pricing.

Taken together: within about a year, an organisation building on OpenAI's tooling could have been asked to move twice.

Why this keeps happening

The agent-building layer is at the stage where vendors are still searching for the right shape. Products ship fast and are replaced fast because the vendors themselves do not yet know which model wins. That is normal for a young technology.

The problem is not that tools change. It is what a company puts inside them. An approval process, a pricing ruleset, a complaints workflow — if those exist only as configuration inside a vendor's product, they disappear when the product does.

For enterprises in Vietnam

The practical conclusion is to separate two layers. Business logic — processes, permissions, calculation rules, data — belongs where you control it and where the lifecycle is long. The part that calls models and orchestrates agents belongs in a thin layer outside, treated as something you will replace.

For companies already on an application platform such as Mendix, that boundary is fairly natural: process and data live in the application, the model call lives in an integration module. Change model vendor and you change that module, not the process. A connection standard such as MCP makes the boundary clearer still.

A quick test for a project already underway: if a vendor announced tomorrow that a product shuts down in six months, what would you lose? If the answer is "we would rebuild the process", the logic is in the wrong place. If it is "we would rewrite the API calls", the architecture is sound.

None of this means avoiding packaged builders. They are genuinely useful for testing quickly and proving an idea. Just stay clear-eyed that a prototype which runs well does not automatically become the foundation of a production system — and do not leave the prototype in place and call it a deployment.

Sources

OpenAI Developer Community — Deprecation notice: Agent Builder (4 June 2026): https://community.openai.com/t/deprecation-notice-agent-builder/1382650

VentureBeat — OpenAI unveils Workspace Agents, a successor to custom GPTs for enterprises (22 April 2026): https://venturebeat.com/orchestration/openai-unveils-workspace-agents-a-successor-to-custom-gpts-for-enterprises-that-can-plug-directly-into-slack-salesforce-and-more