Why Did ChatGPT Plugins Fail? AI Skill Libraries Need to Lower the Discovery Barrier

ChatGPT plugins were once seen as a major breakthrough for the AI assistant ecosystem, but in the end almost no one used them. An analysis video on YouTube points out that the problem was not the capabilities of the plugins themselves, but the friction users faced in discovering and installing them. The video compares the successes and failures of multiple skill libraries and distills a key lesson: let the Agent proactively find and use skills, rather than expecting users to manually enable them.

The Core of Plugin Failure: Users Simply Didn't Know They Existed

The video repeatedly emphasizes one detail: ChatGPT plugins required users to manually enable them. This means users first had to be aware that the plugin feature existed, then actively search for plugins, understand their purposes, and complete the enabling process. For the vast majority of ordinary users, every link in this chain caused drop-off.

"You have to find them first, and most users don't even know this exists," the video notes. Users need to first discover the feature, then search for what's inside it—"nobody does that." This is not a minor flaw in product design but a fundamental defect in the entire distribution logic. The prosperity of a plugin ecosystem depends on two-way matching between supply and demand, but when the cost of discovery is so high that ordinary users are unwilling to bear it, no matter how many plugins exist, they are just silent inventory.

ChatGPT plugins were a feature launched by OpenAI in March 2023, allowing third-party developers to connect external services to ChatGPT so it could invoke capabilities such as web browsing, code execution, and travel booking. Users had to manually enable the plugin feature in settings, then browse and install plugins through a dropdown menu in the conversation interface, and they had to reselect enabled plugins for each new conversation. This mechanism meant that plugin exposure depended entirely on users actively exploring, rather than system recommendations or automatic triggering. The plugin ecosystem attracted a large number of developer submissions in its early days, but actual invocation rates were extremely low, and OpenAI eventually gradually integrated it into the GPTs and custom Actions system in 2024. As a standalone form, plugins essentially exited the stage.

What Successful Skill Libraries Did Right: Reduce Friction

The video reviews the rise and fall of multiple skill libraries throughout history and summarizes the common trait of the successful ones: less friction in the process of finding and installing skills. Skill libraries that worked well often made skills readily accessible, sometimes even eliminating the need for users to specifically "install" anything.

This observation actually points to a more universal product principle: any feature that requires additional learning cost from users will hit a ceiling at scale. The plugin model placed both the choice and the operational burden on users, while users lacked both the patience and the sufficient context to judge which plugin was worth enabling.

Agent Autonomous Invocation Is the Ideal Form

The solution offered by the video is clear: in Agent scenarios, the ideal state is for the Agent itself to decide "I'm going to use this skill," rather than letting users make every decision. This effectively transfers responsibility for skill discovery and invocation from users to the Agent.

This judgment aligns with the current direction of AI product evolution. Agents possess task context and know what problem currently needs to be solved, so they understand better than users what capability is needed at what moment. If skill libraries can be automatically retrieved and mounted by Agents, what users perceive is not the separate concept of "plugins" but a natural extension of the assistant's capability boundary.

An Agent (intelligent agent) refers to an AI system capable of perceiving its environment, making autonomous decisions, and executing multi-step tasks. Unlike passive chatbots, Agents have task planning, tool calling, and contextual memory capabilities, and can independently select the tools or skills needed after the user provides a goal. In skill invocation scenarios, the Agent autonomous mode means the system automatically retrieves and mounts relevant capabilities based on the current task context, rather than waiting for users to pick from a menu. This is consistent with the traditional function calling mechanism: the large model outputs structured invocation instructions when generating responses, and the runtime environment executes the corresponding tool and returns the result. The difference is that Agent autonomous skill discovery requires an additional retrieval layer—semantically matching current needs across a large number of skills—which is more complex than a predefined tool list and is also the core challenge of current skill library design.

Discovery Mechanisms Matter More Than the Number of Skills

One line in the video captures the essence of the problem: "The Agent needs to find them and bring them into your attention." This shifts the focus of competition for skill libraries from "who has more skills" to "who can better deliver skills to the moment they are needed."

For teams building AI applications or Agent platforms, this means evaluation metrics need to change. The total number of skills is not a moat; skill invocation rate and scenario hit rate are. The design questions to answer are: Can the Agent automatically discover relevant skills at the right time? Does the user need extra confirmation when a skill is invoked? Can the enabling process be compressed to zero?

The lesson of ChatGPT plugins is not that the plugin form has no value, but that it left the cost of discovery to the people least motivated to bear it. When the Agent becomes the invoking subject, skill libraries can shift from "users browsing a catalog" to "capabilities appearing on demand." This is also the design principle most worth remembering as the skill ecosystem becomes active again today.

Invocation rate and scenario hit rate are two key metrics for measuring the efficiency of skill distribution. Invocation rate refers to the proportion of times a skill is actually invoked within a certain period relative to the number of exposures; scenario hit rate refers to the proportion of tasks requiring a certain type of capability in which the system correctly retrieves and invokes the corresponding skill. Together, these two metrics reflect the effectiveness of the discovery mechanism: no matter how many skills there are, if the Agent cannot retrieve them at the right time, or if users need extra confirmation to enable them, the invocation rate will approach zero. By contrast, the total number of skills is only a supply-side metric and cannot reflect matching efficiency on the demand side. For platforms, optimizing the discovery mechanism means building a semantic retrieval layer, reducing confirmation steps, and letting skills automatically surface in task contexts rather than relying on catalog-style browsing.