Custom GPT Retirement and the Loss of Customer Truse

Please route this message for human review by the product leadership or custom GPT migration team. This is not a request for technical troubleshooting; it is substantive customer feedback about the custom GPT retirement and plugin migration, based on a deployed educational system using approximately 155 GPTs.

To OpenAI Product Leadership
Subject: Custom GPT Retirement, Plugin Migration, and the Loss of Customer Trust

I am speaking as a long-term paying OpenAI customer who has made a substantial investment in custom GPTs as part of a structured educational system. I currently operate approximately 155 specialized GPTs within Tharaka Invention Academy. These are not experimental chatbots. They are integrated into a large textbook and learning ecosystem in which an apprentice encounters a particular exercise, receives the instructional context from the textbook, and then follows a direct URL to the specific GPT designed to provide the appropriate form of AI assistance.

The simplicity of that architecture is critical. The textbook determines which specialist is required. The apprentice clicks one link and immediately enters the correct environment. The learner does not have to search through ChatGPT, determine which tool is appropriate, install or select a skill, formulate a routing prompt, or depend upon the model to infer which capability should be invoked. The same specialist GPT may be called repeatedly from different parts of the textbook because the surrounding instructional material—not the GPT itself—provides the immediate context for its use.

The proposed migration from custom GPTs to plugins appears to remove this deterministic relationship. A plugin may contain multiple skills, but that does not reproduce a persistent externally addressable URL for each specialist tool. Requiring apprentices to locate a plugin, select a skill, invoke it with an @ reference, search through the + interface, or rely on automatic skill routing introduces unnecessary friction and ambiguity into an instructional process that is presently simple and precise.

This is not merely a matter of inconvenience or resistance to change. It affects pedagogy, usability, development cost, publishing, maintenance, and institutional trust. Hundreds of links and instructional references may have to be reconsidered. Specialized GPTs must be migrated, tested, validated, documented, and supported again. Learners may experience greater confusion. Organizations such as mine may be forced to create new routing systems simply to restore functionality that already exists today.

There is also a serious issue of downstream reputation. When an OpenAI platform change disrupts a system that my apprentices or institutional partners use, they encounter the disruption through Tharaka Invention Academy. They may not distinguish between a decision made by OpenAI and a failure by our organization. OpenAI therefore transfers not only technical and financial costs to customers, but potentially reputational costs as well.

What is especially troubling is the apparent absence of meaningful advance consultation with affected custom-GPT creators. OpenAI could easily have announced that it was considering this architectural change and invited voluntary input from customers using GPTs in education, publishing, business workflows, research, and other structured environments. A simple question such as, “Do you distribute custom GPTs through direct URLs embedded in books, courses, websites, or operational systems?” would immediately have revealed use cases that are not well served by the proposed replacement.

Consultation would not have required OpenAI to surrender its decision-making authority. It would simply have allowed the company to understand what customers had actually built before finalizing an architecture intended to replace it.

There is also a problem with the escalation process itself. OpenAI’s support documentation indicates that unresolved matters may be passed from the virtual assistant to a human agent. In my case, that did not occur in any verifiable way. The automated exchange simply stopped without further response and without confirmation that a human representative had reviewed my concerns. When a major platform transition is already imposing substantial costs and disruption on customers, the absence of a dependable human escalation path compounds the loss of trust.

The result is a significant loss of confidence in OpenAI as infrastructure. OpenAI encouraged customers to build on custom GPTs, and many of us did so in good faith. We invested time, intellectual property, instructional design, publishing infrastructure, and organizational credibility around capabilities that are now being fundamentally changed. The lesson customers may draw is not merely that custom GPTs are temporary. It is that any OpenAI-specific architecture may be subject to unilateral replacement after substantial customer investment.

I urge OpenAI to reconsider at least one crucial part of this migration: preserve a mechanism by which an individual migrated specialist skill can be directly and persistently invoked through a stable external URL, without requiring the user to search, select, install, configure, or explain which capability is needed. For systems such as ours, direct addressability is not a convenience. It is part of the instructional architecture.

More broadly, I urge OpenAI to engage affected creators before completing this transition. A technically elegant architecture can still be a poor migration if it destroys valuable workflows customers have already built around the previous one.

I am therefore requesting two things: first, that OpenAI preserve a mechanism for direct, persistent invocation of individual migrated specialist tools through stable URLs; and second, that this feedback be reviewed by a human member of the product leadership or migration team, with confirmation that such review has occurred.

The central concern is simple: OpenAI is solving an architectural problem for OpenAI while transferring much of the resulting complexity, cost, and risk to its customers. That is not a sustainable basis for long-term trust.

Professor J. Singer
Tharaka Invention Academy
Tharaka Invention Circle

(4)